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

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

On Thu, Mar 11, 2010 at 11:32 PM, Johnny Billquist <bqt%softjar.se@localhost> 
wrote:
> 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.

Yes, keeping track of state is complex.

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

You're only pointing out that "managing static thing statically" is
easy.  Everyone already knows that.

What we're talking is what we don't have now.

Masao