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

[Adam Hoka <adam.hoka%gmail.com@localhost>]

On Fri, 12 Mar 2010 00:35:24 +0900
Masao Uebayashi <uebayasi%gmail.com@localhost> wrote:

> On Thu, Mar 11, 2010 at 11:50 PM, Masao Uebayashi 
> <uebayasi%gmail.com@localhost> wrote:
> > 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.
> 
> Speaking of tracking state...  I've found that keeping track of state
> in devfsd is very wrong.  It duplicates what filesystems already does.
>  So what we need for emulating "traditional" view is a way to proxy
> those state bits nicely (probably to tmpfs).
> 
> Speaking of persistency, I come to think it's totally *not* worth in devfs.
> 
> So users have two options:
> 
> - Traditional /dev
>   - Fine grained access control
>   - Persistent
>     - Relying on UFS (or whatever)
>   - Static configuration
> 
> - New /dev
>   - Simplified access control
>   - Volatile
>   - Dynamic configuration
> 
> Masao

Im wondering if it would be too hack-ish to make devfs file
backed (at least optionally, in case of early boot or read
only rootfs).

For example: mount -t devfs /etc/devfs.db /dev

So it could be persistant without a userland process.
Or is this something that would be complicated?

-- 
NetBSD - Simplicity is prerequisite for reliability