Linux-kernel mailing list archive 1998-31,: Re: DEVFSv50 and /dev/fb? (or /dev/fb/? ???)

# Re: DEVFSv50 and /dev/fb? (or /dev/fb/? ???)

Richard Gooch (Richard.Gooch@atnf.CSIRO.AU)
Wed, 5 Aug 1998 11:45:09 +1000

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: David S. Miller: "Re: pre-2.1.115-2 fails compile pgtable_cache_water"
- Previous message: Matthew D. Pitts: "Re: gcc 2.7.2.3 vs gcc 2.8.1"
- Next in thread: Alan Cox: "Re: DEVFSv50 and /dev/fb? (or /dev/fb/? ???)"
- Reply: Alan Cox: "Re: DEVFSv50 and /dev/fb? (or /dev/fb/? ???)"
- Reply: Andrea Arcangeli: "Re: DEVFSv50 and /dev/fb? (or /dev/fb/? ???)"

Andrea Arcangeli writes:
> On Tue, 4 Aug 1998, Shawn Leas wrote:
>
> >Specifically, what is ugly about it? Is it intrinsic in nature, or
> >something fixable? Is the design flawed? Then how? Back up your
>
> I don' t know about the Theodore idea of ugly but I agree with him. _I_
> see devfs flowed by its start. I just explained my thoughts about devfs
> some month ago before the first release of devfs. devfs is a workaround.
> We would not need devfs at all if the kdev_t would be a 64 bit unsigned
> integer.
>
> Instead of reply me that with devfs the root device _can_ be mounted
> readonly and we _can_ boot with a root fs with no major/minor number
> support, please tell me that you need to use these features. We could also
> write a videogame in the kernel and eventually play with it before mount
> the root device if you really want not used features (even if this example
> is not the right one, the exciting videogame probably would be played a
> lot ;-).

I don't know how many times I need to repeat this: devfs is *not* just
about working around the size of kdev_t or having a read-only or
non-Unix root FS.

The thing that really motivated me to start it was the horrible SCSI
disc naming scheme (take out one ID and play musical chairs with your
device names) and the fact that you have to have zillions of inodes to
support all the possible SCSI discs you could have. Right now you need
256 inodes in /dev to ensure you can use and of the possible discs and
partitions. Later as we support more SCSI discs, the number of inodes
will have to be increased. Distributions will have to ship systems
with /dev having thousands upon thousands of inodes. This is a
joke. Apart from being incredibly ugly (having a huge /dev), having
lots of inodes means that directory searches are quite slow.

I've heard the suggestion that you use initrd to populate /dev
automagically. IMHO that is simply silly. Firstly it takes time to
create all those inodes (for devices you have). When you shut down you
should probably remove those inodes. *This* is cleaner than devfs???
If people want to automagically populate /dev from userspace, it
requires information from the kernel (current boot logs do not provide
sufficient information). Making the boot logs spit out information for
every device file available is no good: the boot logs will be too
cluttered. Creating a special /proc entry is better, but still
requires hacking lots of drivers and then we have the inevitable
problem where the format changes so the userspace tool has to be
changed. Yuk, yuk, yuk.

> I had to say that I never tried devfs and that it could be a very
> confortable workaround but I can' t like it ;-). Probably I' ll try soon
> though. I' m afraid to say this again and after the sure good work of
> Richard...

I would dearly like to hear practical solutions to *all* the issues I
raise in the devfs FAQ. Every time this discussion comes up, I hear a
selective subset of the issues which conveniently ignores all the
other issues that devfs addresses. This then leaves some people with
the feeling that "devfs is flawed, ugly and/or unnecessary", because
they haven't thought about all the issues I raise in the FAQ.

Regards,

Richard....

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html

- Next message: David S. Miller: "Re: pre-2.1.115-2 fails compile pgtable_cache_water"
- Previous message: Matthew D. Pitts: "Re: gcc 2.7.2.3 vs gcc 2.8.1"
- Next in thread: Alan Cox: "Re: DEVFSv50 and /dev/fb? (or /dev/fb/? ???)"
- Reply: Alan Cox: "Re: DEVFSv50 and /dev/fb? (or /dev/fb/? ???)"
- Reply: Andrea Arcangeli: "Re: DEVFSv50 and /dev/fb? (or /dev/fb/? ???)"