On Thu, Mar 11, 2010 at 10:37 PM, Masao Uebayashi <uebay...@gmail.com> wrote: > On Thu, Mar 11, 2010 at 2:49 AM, Jochen Kunz <jk...@unixag-kl.fh-kl.de> wrote: >> Somthing else comes to my mind: Kernel configuration and devfs >> configuration interact closely. E.g. you can give the device >> enumeration order in the kernel configuration by "nailing down" >> devices. Now those symbolic kernel devices like com(4) need to be >> assigned to a device node name in /dev. >> >> Why separate those two? There should be a single configuration file >> that configures kernel options like what device to search where and >> what device node to assign to it. (+ permissions and ownership etc.) >> This file is used to get the kernel default configuration at compile >> time. Now this file should be passed to the kernel at boottime >> optionally. Thus makeing the kernel reconfigurable at reboot. In >> addition the in-core version of that file must be runtime alterable. >> This way you can en-/disable device drivers at runtime, probably >> resulting in the (un)load of a kernel module and creation or delition >> of device nodes in /dev. The current kernel configuration can be dumped >> to a file and passed to the kernel at next boot... > > Sounds interesting, but hard to grasp your view exactly. Examples help.
OK, this is something like, config exploring buses with the whole tree image as a recipe. IIUC this is exactly what ACPI needs. You build a whole tree from ACPI table, then enter configure(), build cfdata on-the-fly and give it to *_attach(). Bus drivers may have to be changed to pass its subtree to config_found()... For permissions, they're probably going to be per-mount (== per-view). We should concentrate on physical topology / connection during configure(). Masao
