Re: kernel-managed /dev, revisited

Teunis Peters (teunis@usa.net)
10 Jul 1997 23:00:25 +0200


I agree completely! (have overloaded SCSI system, have to move stuff
around a bunch).... Already using symlinks 'cause tired of moving devices!

On Thu, 10 Jul 1997, Jeff Garzik wrote:

<snip running commentary and history>
> Here's what I propose...
>
> Each device registers an entry in a procfs structure, which creates (to
> the user) a procfs device file. Major kernel subsystems handle their
> own registries. I can best describe this with an example of kernel
> boot-up. "procdev" is what I call this new feature.
>
> 1. Kernel init. procdev root structure init.
> 2. SCSI subsystem init. Adds subdirectory "scsi" to procdev struct.
> 3. BusLogic driver init. Adds several device entries to the procdev
> scsi subdirectory...
>
> /proc/dev/scsi/h0t3l0
> /proc/dev/scsi/rh0t3l0
> /proc/dev/scsi/h0t4l0
> /proc/dev/scsi/rh0t4l0
>
> h0t3l0 = host #0, scsi id[target] #3, LUN #0
> An 'r' prefix to the device name indicates a raw device.

What about multiple SCSI adapters? (host#, right? That's not too likely
to move all that often....)

> 4. Ramdisk driver init. Adds ramdisk subdirectory to procdev struct,
> and adds several entries to the subdirectory.
>
> /prov/dev/ramdisk/0
> ...
> /prov/dev/ramdisk/3
>
> The key to /proc/dev's success is its correctness. The devices listed
> in /proc/dev are absolutely guaranteed to exist on the system, and their
> device major/minors are 100% accurate.
>
> The current /dev structure continues to exist, of course. Distribution
> maintainers can choose whether to hand-maintain /dev -- like they do now
> -- or symlink the /dev entries to their proper names in /proc/dev.
>
> The ultimate in spiffiness would be a boot parameter to the kernel,
> which would say "yes dammit, scramble my /dev" -- in other words, have
> the kernel update /dev such as all its entries point to /proc/dev
> locations. /dev/sda would point to /proc/dev/scsi/h0t3l0, etc.

Or just ignore /dev altogether :) Use the /proc/dev pool as kind of a
hardware detection probe :)

.... makes it ... difficult ... to autoprobe devices if you do this
though. (not that it affects this idea any).

Thanks!
- Teunis

Mind you, it'd affect the kernel size some, wouldn't it?
[vtable of links between devices and a name table...]
[/proc/dev entry to lookup those names in (active?) device list]
Other than that, it shouldn't affect things any and named device drivers
would be nice :)