Messages in this thread | | | Date | Thu, 10 Jul 1997 11:18:20 -0600 (MDT) | From | Teunis Peters <> | Subject | Re: kernel-managed /dev, revisited |
| |
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 :)
| |