On Fri, 12 Mar 2010 00:35:24 +0900 Masao Uebayashi <uebay...@gmail.com> wrote:
> On Thu, Mar 11, 2010 at 11:50 PM, Masao Uebayashi <uebay...@gmail.com> wrote: > > On Thu, Mar 11, 2010 at 11:32 PM, Johnny Billquist <b...@softjar.se> 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