> Here's one possible compromise... have /proc/dev have all of the devices,
> with their suggested names, owned by root, with permission 000.
(This discussion is also going on in usenet too, in c.o.l.d.s I
think).
Overall, I think that having a kernel-generated /proc-like /dev is a
good idea. Only the devices that are compiled into the kernel (and
specified by the system at bootup) will be needed.
My /dev directory here has over 500 entries! It would be nice not to
see all the unnecessary ones... I don't have scsi or cdrom (bummer:),
so what do I need with all the /dev/sd* and cdrom device files? If I
compile scsi or cdrom or sound support etc into the kernel, then the
devices will appear automagically in /dev.
Things like extra /dev/tty*'s could be dynamically created (and
destroyed) as they are needed (and no longer needed).
Seems to me to be a good idea. There's a nice eligance to it all.
(Or perhaps just more ways for things to go terribly wrong? :-)
> A simple script can move them to /dev and rename, chown and/or chmod
> them at boot time to useful values.
Perhaps this could all be done with a /etc/dev.conf file, similar to
the way, for example, how /etc/fstab is used.
A (dev.conf-aware) utility to create/delete/modify devices at
anytime (not just at bootup) would be useful (necessary?).
And a /dev in kernel memory could also work seamlessly with any /dev
directory device entries on the hard drive. So "ordinary" files and
scripts etc could live in /dev like they can now, and can be used in
conjunction with the /etc/dev.conf file. It would all become seamless
(but possible to distinguish between them with the above-mentioned
util).
The current system tools should also be allowed to do the job too:
> Unix has lived with the wierd /dev system for a while, so it's
> definitely not fatal to stick with it, but that's an alternative to
> needing to put rename, chmod, chown, etc. into the kernel for a
> kernel-level /dev.
...not to mention creating links like /dev/modem to /dev/cua0 etc.
It's all possible, although I admit that I can see potential problems
that will need to be resolved in a sane manner, like conflicts between
what's been compiled into the kernel, what /etc/dev.conf says, and
what is actually in the hard drive's /dev directory.
And on a programming level, it should also be possible to interface to
these virtual kernel devices through appropriate C calls so that
customised devices etc can be used. (Perhaps they exist already...
it's not something I'm intimitely familiar with).
Just my humble 0.05c worth...
Cheers
Tony
-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-
T.Nugent@sct.gu.edu.au tnugent@cit.gu.edu.au tonyn@sctnugen.ppp.gu.edu.au
-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-=*#*=-
In success there's a tendency to keep on doing what you were doing. -- Alan Kay