[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: (Semi-random) thoughts on device tree structure and devfs
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
Im wondering if it would be too hack-ish to make devfs file
backed (at least optionally, in case of early boot or read
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
Main Index |
Thread Index |