On Thu, Mar 11, 2010 at 11:32 PM, Johnny Billquist <[email protected]> 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
