You're still throwing _WAY_ too much complexity at things here! K.I.S.S. At Mon, 22 Jun 2009 06:27:23 -0400, Matthew Mondor <mm_lists%pulsar-zone.net@localhost> wrote: Subject: Re: FreeBSD devfs support on NetBSD 5.0 > > Interesting, I like the persistency and transparency level this would > achieve... Indeed -- I've never been able to really conceive of any other way to do it! :-) > A main question possibly is how flexible must a devfs be about device > permissions and visibility control? That's the thing -- with the unionfs overlay, and with basic ability to change them at every boot until shutdown it's not that important a question to worry about. > In case we want to maintain the total visibility and permissions > control which we have with the legacy system, I don't see an obvious > way on how to totally eliminate the need for at least a basic set of > permissions/visibility rules. Yes, of course, drivers and/or some other compile-time component (perhaps an extension to secmodel(9)) would provide basic sane defaults for ownerships and permissions. (device visibility is not a concern -- mount it read-only if you don't want new devices to appear in your chroot area, but if you do want to see new devices pop up in a chroot area then you need to come up with a new security model because your current one is broken by its design :-)) > This appears to be an aesthetic concern, but should a "downed" > removable device also cause its corresponding entry to become > invisible? I don't know the for sure -- I would say an administratively down device should not disappear from devfs, but one that is hard-down or disconnected should disappear. This part though is all more a question for those more interested in truly dynamic runtime device control. The current state of configuring mostly everything at boot time and then building devfs from the autoconf tree would give us a first good go at "something that works" and works well enough to use in production. Initially I would only support dynamic creation of nodes for bus types where we already support dynamic connection of devices, such as SCSI, USB, etc. I really do want sdNN to appear when it's attached by "scsictl scan", and I do not want a farm of all possible /dev/scsibus0/* devices to appear at boot time, and I probably also want it to disappear after "scsictl detach". > If so, the overlay could indeed also hide it while > retaining the lower layer persistent node (or updated metadata) to > restore visible permissions if instanciating the node again. Interesting idea, but I think the upper layer needs to be totally disconnected from the lower layer in terms of actual device management. For a clean and simple initial design the upper layer should probably store _only_ metadata and metadata alone. Once people get good real-world experience with the most basic and elegant (but usable) design then we can see if/how it needs to expand. This is the unix way, after all. Come up with an idea, implement the basics, try it out, go only so far as you need to in order to use it in production, spread it around, see if others can use it too. Never introduce complexity where you don't really need it, especially not at the design level. I'd say even use of white-out files is too much complexity to begin with for this purpose, but they're nothing new and we already have and support them, so "we" may as well give everyone the completeness they offer and "we" will hopefully face far fewer initial criticisms. > If I understand however, if more than one devfs mount is to exist, it > couldn't share the same backing persistent files without introducing > races if they updated them, and this is where the need for > mountpoint-specific persistent metadata arises? I would never conceive of trying to use the same upper layer for multiple mounts -- that's just asking for trouble. K.I.S.S. Multiple devfs mounts would instantiate whole new separate data structures in devfs, and multiple unionfs mounts would require separate backing-store directories. > I see a few possibilities here (I've actually also wondered if puffs I think PUFFS is _WAY_ too may layers -- devfs should be a kernel level implementation. It seems on the surface at least not a difficult thing to do now either as there are at least two easily available prototype implementations to draw from, and perhaps more will pop out of the woodwork if we can do as I say and throw away the persistence requirement for devfs itself. I think mount_union(8) as extended to support devfs also needs to stay much the same as it is. It's already somewhat well debugged and understood too, so extending it to support devfs is a no-brainer, at least as far as I can tell. Maybe it does need to be rewritten given the number of war stories and bug reports about it, but that wouldn't be a bad thing either. -- Greg A. Woods Planix, Inc. <woods%planix.com@localhost> +1 416 218-0099 http://www.planix.com/
Attachment:
pgpudaEYQXZvO.pgp
Description: PGP signature