lkml.org 
[lkml]   [1998]   [Jan]   [3]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
DateSat, 3 Jan 1998 00:22:56 +1100
FromRichard Gooch <>
SubjectRe: PROPOSAL: /proc/dev
Linus Torvalds writes:
> 
> 
> On Fri, 2 Jan 1998, Richard Gooch wrote:
> > 
> > I agree. Loading and unloading is 'orrible. The latest thinking is:
> > [ edited ]
> > 
> > If a process tries to open() an entry in /dev which does not exist,
> > devfs passes the name of the entry to kerneld. It is up to kerneld to
> > convert filenames to modules (i.e. "ttyS{0,1,2,3}" to "serial").
> 
> Sorry, no. 
> 
> I refuse to use a kernel that depends on kerneld. That's final. 

I'm not proposing a kernel that *depends* on kerneld, only one that
can support it.

> This is a design issue. I don't like a crippled kernel - I want the kernel
> to be stand-alone, and be able to function on its own. It shouldn't do
> policy decisions, but is should also not just flail wildly around when
> something strange happens. That way lies madness (Windows NT to be exact). 
> 
> In short, it needs to be self-sufficient - it's ok to have an entity like
> kerneld, but it is NOT ok to depend on anything like kerneld for the
> system to do some really fundamental tasks. Opening a device is a really
> really fundamental task - requireing that kerneld is up and running is not
> an option. 
> 
> For devfs to be usable, it has to be able to run on its own - possibly
> with very strict limits. For example, all the files might be owned by
> root:root, with permissions -rw------- at bootup. Such a system still
> _works_ - it just requires root to log in and fix things up (obviously
> done with a script in rc.d, but the point is that the system _can_ come up
> in single-user mode even without anything like kerneld). 

I agree completely. I don't even use kerneld myself, but I feel that
devfs should be able to support it.
The reason my scheme doesn't depend on kerneld is that if a driver is
built-in/loaded by a boot script, the /dev entries for that driver are
registered in the startup code. So, on a system like mine where all
drivers are either built-in or automatically installed by a boot
script, /dev would be fully populated. An attempt to open(2) an entry
in /dev which did not exist would cause devfs to return -ENODEV
because kerneld isn't running.
All the other semantics of changing default file permissions will
still work fine.

Note that individual drivers would determine the default
protections/uid/gid's. For a hard disc that would be -rw------- 0,0 but
for /dev/ttyp* it would probably be -rw-rw-rw- 0,0.
So, do you still see this as a dependence on kerneld?

				Regards,

					Richard....
\
 
 \ /
  Last update: 2005-03-22 12:41    [from the cache]
©2003-2008