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....