[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: (Semi-random) thoughts on device tree structure and devfs
Masao Uebayashi wrote:
On Thu, Mar 11, 2010 at 2:49 AM, Jochen Kunz
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.
I missed when Jochen wrote this, so I'll comment now.
This might sound tempting, but I don't think it is a good idea.
Keeping track of changes and trying to retain them over reboots is
risky. And the mappings need to be able to handle complex things, such
as several names pointing to the same device. And people using totally
different names. So, both renames, chmod, chown, unlink and mknods needs
to be tracked.
So, what we have basically done, at that point, is to reimplement what
we already have, but in a more complex way.
All for the sake of getting a default entry in there for a virgin
system? (Or when would this actually be helpful?)
In fact, even more complex - what do we do if someone removed a device
entry, for which a device exists? Do we keep track of it in that
database, marked as deleted then perhaps? Otherwise it would be
recreated at next boot? What about a new kernel? Should we wipe the
database? That might not be the right thing to do. Should we keep it?
That might also be right - after all, this is a new kernel... We might
have added some devices. Should they turn up or not?
Nah, I don't see any gains. Only losses. The current entries in /dev is
working better than this, in combination with MAKEDEV, which you can run
if there is something you do want to add which is missing, with default
values. After that, you can fool around with, and modify to your hearts
content, without anything unexpected happening under your nose when you
didn't expect it.
Main Index |
Thread Index |