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

Terry L Ridder (terrylr@tbcnet.com)
Tue, 04 Aug 1998 22:51:35 -0500


Richard Gooch wrote:
>
> 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 am well aware of the current SCSI naming convention and what you
consider "ugly" I consider "simple beauty". I am pushing the SCSI
disk limit on one machine.

Do I like the way /dev/sd? is rearranged when I pull a hard drive out
of the SCSI expansion box? Well no, but I have learned to live with
it for the time being. I have repeated posted stating that the Linux
Community has roughly 3 months to design an enhancement to increase
the SCSI drive limit, and deal with files > 2GB on Intel hardware.

(Before someone blasts me about the DEC Alpha and Sparc 64 supporting
> 2GB files, yes I am well aware of that. I have a DEC Alpha 433MHz
setting next to me in my home office.)

Then we have three months to code and test it. That time frame is
based on the projected release dates given by Oracle & Informix for
their Linux products.

The Linux Community has been asking for this type of support and we
either welcome it and provide for it or the next major software vendor
will think twice about supporting Linux.

Richard, I for one would rather live with thousands and thousands of
inodes in /dev/ than live with the "ugly" naming scheme of dev_fs.

I readily agree that directory searches of a large /dev are slow
but again I would rather live with a slow directory search than with
the "ugly" naming scheme of dev_fs.

We need to keep the "KISS" principle in mind. While the naming scheme
of dev_fs may be logical it is not simple.

/dev/sda, /dev/sda[1-15] is simple.

>
> 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.

Richard, I have read your FAQ where the naming scheme for SCSI disks
is described and it screams "ugly".

>
> Regards,
>
> Richard....
>

-- 
Terry L. Ridder
Blue Danube Software (Blaue Donau Software)
"We do not write software, we compose it."

When the toast is burnt and all the milk has turned and Captain Crunch is waving farewell when the Big One finds you may this song remind you that they don't serve breakfast in hell ==Breakfast==Newsboys

- 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