Well....
I don't know who started the idea of /dev being generated by the kernel,
but I'll speak from Solaris 2.x experience:
When you first start a Solaris 2.x machine, it does a configuration of the
system, which includes a probing for the connected devices (Which it store in
/devices/long/paths/which/sometimes/only/make/sense/to/SMCC ;^), and
then ONLY add links in /dev. Quite a need way of keeping /dev clean from
any unnecesary stuff.
When you add so extra stuff like a extra ethernet adapter, an extra disk etc.
you do a reconfiguration boot, which then recreates /devices, and the links in
/dev.
Since the Linux kernel does a probe in any case when booted, the /devices step
is already there, the only thing left will be the links in /dev which
might/could/should/would be done by a startup script.
>
> > Here's one possible compromise... have /proc/dev have all of the devices,
> > with their suggested names, owned by root, with permission 000.
> >
> > A simple script can move them to /dev and rename, chown and/or chmod
> > them at boot time to useful values.
>
> I'd rather see a single file containing all the necessary information.
> The file would then be parsed by a utility to generate the appropiate
> /dev/* files.
Agree, but ....
>
> > 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.
>
> What would be the advantages of this over the current system? (BTW, the
> chmod, chown and rename are _already_ in the kernel.)
Well, to start of:
1) Kernel generated Major/Minor numbers
2) Hooks for dynamic loading of modules might be easier (I DON'T speak from
kernel hacking experience on this one, only from gut feelings)
3) The place where you put the nth partition from the kth disk connected to the
mth controller's device name & Major/Minor numbers, might be tree structured
for (I'm still not convinced but...) easier/flexible device finding.
Who would have know that /dev/hdc is on the second IDE controller??
What will the fourth disk on the second SCSI controller be called??
if we could place the second IDE controller's first disk's third partition in
let's say:
/devices/ide1@irq14:iop0x170/disk0/part3
then you could ALSO see that it's using irq 14 and I/O Port 0x170.
This is ideas I've seen from SMCC & Solaris, which I think could well be used
in Linux to great success.
Well, think about this...
------
Groetend / Sincerely Yours
Hendrik Visage
#include <Standard/Disclaimer>
Vector Customer Support
+27 11 315 4330
hendrik@vector.co.za