> 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.
Exactly. I administrate (with other students) a Sparc 10 Model 40
running Solaris 2.4 used to give Internet access to the students of our
university. I find it quite annoying to have to reboot the server to
reconfigure it because we added a device.
> > 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
Does this mean dynamic major/minor numbers?????
One advantage of having unchanging Major/Minor is that you can create a
device anywhere on the fs and you can be sure it will _always_ mean the
same thing. If I remember well some ftpd require to have /dev/zero (or
another device) in their home. There are probably other programs that
need this. I'm not sure exactly what it Solaris 2.x does but I would
guess that the Major/Minor are not kernel generated.
> 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)
Hmm... I don't see how it would help. The existence of a /dev/whatever
file on disk does not depend on the existence of the corresponding device
driver in the kernel. For example, the existence of the /dev/ftape file
does not depend on the state (loaded, unloaded) of ftape. OTHO, the
device file must be there to use the ftape module... but since it is
always there anyway...
> 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.
In three years of administering a Sparc we never had to verify where was
connected a disk or any other device. This information is likely to be
required only by the sysadmin. I think that he/she should already know
where the devices are connected whithout having to scan /devices. In case
he/she needs to verify this, dmesg can be used to dump the boot info to
the screen. (Quite usefull also for hardware configuration problems.)
Again, all this information could be stored in a /proc file. I don't like
much the idea of:
- having to reboot for the system to acknowledge the existence of
an external device (like an external SCSI CD player).
- having a script that plays with my /dev files.
> This is ideas I've seen from SMCC & Solaris, which I think could well be used
> in Linux to great success.
If you or someone else wants to implement it as an optional feature, it
would be interesting. People will have the choice between the old or the
new mechanism. Your idea would probably be interesting for a segment of
the Linux community. For example, users migrating from systems like
Windows or Mac would probably like this.
Cheers,
ldd