> "Albert D. Cahalan" <acahalan@cs.uml.edu> writes:
>
> > I've seen a few "nothing is broken" posts. Things _are_ broken.
> > Leaving aside the issue of a bloated /dev full of junk I don't
> > have, there are some serious reasons for a devfs. It needs to
> > be a real devfs too, not some weak hack.
>
> The reasons below amount to "we need a devfs because"
>
> "#1. Non-unix fileystems don't support devices". Excuse me while I
> cry. They also don't support a/c/m/times, hard links, long case
> sensitive filenames, reasonable performance, unix sockets, and inode
> numbers. Why focus on devices? Face is, non-unix filesystems will
> never have the feature set of unix filesystems. That's what the
> 'non-unix' bit means.
At least one non unix FS does support most of the features. Give it up.
Yes, it's a strange thing....
> "#2. Ptys aren't very clean". No kidding. But there are much much
> better ways of fixing the ptys than building a devfs. Ptys have a
> fairly specific problem that nothing else in the /dev world does.
If any 'better' scheme you suggest involves having a inode on disk for
every open pty then you are crazy... On a large system with hugh numbers
of people online there you have to be many inodes, furthermore, every
access to a pty (and every chown and all) would require updating the
times, a serious overhead hard disk wise.
> > *** Read-only filesystems ***
> > [ .. ] The Linux root filesystem can not be read-only because the
> > normal /dev must be read-write to allow tty ownership changes.
>
> No to mention utmp, wtmp, any sort of logging, etc. Fact #1. A read
> only filesystem is always going to be a very special case. Fact
> #2. Nothing stops you building pty's on a seperate read-write
> filesystem.
I dont think it's that special a case.. But you do have a point there..
> > *** NTFS ***
> non-unix file system.
Ahh, but it is posix complient, and would be useable with the adition of
devfs..
Those were some of the weaker arguments against devfs...
This biggest argument, is having devfs reflect what is actually in the
system.. Secondly, a devfs would be the only sensible way of accomplishing
this goal, with our world of loadable modules, pcmcia, and hotswap scsi..
Another argument for devfs, is a sane scsi enumerating scheme (look to
other posts to find out why it's needed).. It would be difficult do handle
this (just to handle a single controler worth of names, accounting for
setting up names for 6 partitions and 3 luns would require 864 nodes,
idealy you would want to support 3 controlers, and the maximum luns
available)..
A minor argument is the access to the disk whenever a owner (or time)
update happens..
There are other arguments but these are the things that annoy me most.