'most'.
> > "#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.
Laugh. Think 'caching' which is done right now for the current
scheme. Even 1000 people logged in for 2000 inodes is a trivial number
of inodes.
> > > *** NTFS ***
> > non-unix file system.
>
> Ahh, but it is posix complient, and would be useable with the adition of
> devfs..
Posix complient means nothing. Go and see what you actually need to
make posix. It's bugger all. Certainly not a terribly useful system.
pty's aren't minimal posix to start with, ditto devices!
> 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..
No, the sensible way is to have the dev /dev/blah, which return ENODEV
if the hardware isn't loaded. Wait! I think that's what we do now! oh
no! Doing a sensible thing now without a devfs, how can I live. :)
> 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)..
This isn't an argument for devfs. This is an argument for a larger
dev_t size. Before you can claim this as a reason for building a
devfs, you need to detail exactly how a devfs is magically going to
fix the above problem.
> A minor argument is the access to the disk whenever a owner (or time)
> update happens..
The only way you can prevent this is keeing everything in memory, and
throwing all the timestamps away when the machine reboots. I think not.
> There are other arguments but these are the things that annoy me most.