Fine, you don't like the new naming scheme. That's why the old names
are still there. If you are deeply wedded to the old names, you are
welcome to them. I'm not *forcing* you to use the new naming
scheme. Go ahead and use the old names.
> 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.
How about /dev/sd{a,b,c...} entries only for the discs you have? You
can have that right now with devfs.
> 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.
Again, just use the old names: I didn't take tham away.
> 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.
And you can keep using it.
> > 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".
So ignore the new names and keep using the old names. Nothing in your
message talks about devfs itself, you're only addressing the minor
issue of naming, which is in fact not a problem.
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