lkml.org 
[lkml]   [1998]   [Aug]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: DEVFSv50 and /dev/fb? (or /dev/fb/? ???)
Date
This definitely has some useful qualities, however some things do not need
to be changed over to new names. The IDE devices comes immediately to mind.
There can only be 8 EIDE devices on a system and the device names for EIDE
and each device name is already is mapped to a specific drive location.
(ex. /dev/hdc = Second Master) (Note: /dev/hda is much, much simpler and
understandable than /dev/IDE/hd/c0b0t0u0, especially considering that
c0b0t0u0 is completely unnecessary when c0d0 would do (c = chain, d = disk),
if not /dev/IDE/[0-7]. There is also only 4 possible standard serial ports
and 3 possible standard parallel ports. Also only two possible floppies.
And if I remember correctly the floppies and serial ports are also mapped to
specific locations. (ex. /dev/fd0 = A: Drive, (Perhaps parallel ports
should be as well?)) Furthermore there are many other devices which can
only be installed one or a few to a system. These are also probably the
most common devices found on most Linux users' systems. Since this is the
case it is my opinion that at least these common, limited, devices should
continue to be /dev/[devicename]. And if devfs takes over the /dev
directory these devices still do not have to exist in a file system (saving
a little space) and should still be able to avoid the device number
limitation problem. This has the added benefit that it help maintain
backward compatibility for the majority, if not vast majority, of Linux
users. Only changing what needs to be changed, especially SCSI/
USB/multiport adapters/etc which can have a large number of devices. As far
as being able to scan a devfs /dev and figuring out which devices exist and
which do not, what happens in largely modularized systems like most of mine,
which have much of the kernel in auto-loading/unloading modules? Since the
most popular distribution also seam to make heavy use of
auto-loading/unloading modules this might be a widespread problem/oddity.
Perhaps a device's, apparent, existence (due to a loaded driver) should be
indicated in a different manner? Maybe through using one of the unused
permission bits, or an alternate "known present" devices proc entry like
/proc/devices/. Of if possible, only having devices exist as entries in the
directory with no actual disk space allocated to it. But this is probably
only doable in the filesystem code. (Note: this could be good for ext3.)
Basically I think this is generally a good idea, but the changes to device
names should be limited only to those devices that need the name change like
SCSI/future USB devices/multiports/etc. EIDE/floppies/serial ports/parallel
ports/etc do not need a name change and should be left as is. Super long
device names easily become verbosely cryptic and should be avoided whenever
possible (ex. /dev/IDE/hd/c0b0t0u0).

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



-
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

\
 
 \ /
  Last update: 2005-03-22 13:43    [W:0.094 / U:0.488 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site