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