lkml.org 
[lkml]   [1997]   [Jul]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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 :)

\
 
 \ /
  Last update: 2005-03-22 13:39    [W:0.123 / U:1.464 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site