Re: (Semi-random) thoughts on device tree structure and devfs

[Masao Uebayashi <uebayasi%gmail.com@localhost>]

On Thu, Mar 11, 2010 at 10:37 PM, Masao Uebayashi 
<uebayasi%gmail.com@localhost> wrote:
> On Thu, Mar 11, 2010 at 2:49 AM, Jochen Kunz 
> <jkunz%unixag-kl.fh-kl.de@localhost> 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