Re: exact semantics of union mounts (and TRYEMULROOT)

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> some relatively obscure OS most of them have likely never heard of
> Should we have an arbitrarily different, i.e. wrong, implementation
> of, say, telnet, because it originally came from some relatively
> obscure OS most people now have likely never heard of?  SunRPC?  NFS?
> OpenGL?

Telnet, RPC, and NFS are network protocols that require some kind of
spec conformance in order to interoperate.  That said, note that we do
indeed have different versions of at least a few of those; our telnet
behaves differently from Windows telnet (though I think neither
behaviour contravenes the spec), and our NFS has two different
standardized versions (v2 and v3) and also has NQNFS, which I think
could defensibly be called an arbitrarily different (and thus "wrong")
implementation of NFS.

mount -o union and mount -t union are private to the system they are on
and, as such, do not have that kind of interoperability issue.  Should
we, say, remove mount -o async because VMS (which predates most current
Unices and certainly predates NetBSD) doesn't have it?  (I don't know
whether VMS actually has any analog of it or not; I don't recall any,
but those memories are at least thirty years old and are of
then-current VMS.)  Should we remove Nagle from our TCP stack because
the systems TCP was invented on/for didn't do it?

OpenGL is an interesting case.  It is system-private in that it is not
a network protocol, but has a spec anyway for the sake of portability
of calling code.  Union mounts do not, per se, have that issue, but
there is an analogous issue at the human layer.

And that, I think, is one of only two bases I can see for wanting our
union mount semantics to match Plan 9's: (1) so that human knowledge
and experience can transfer between them and (2) if 9's semantics are
more useful, we can get the benefit of them.

(1), while having some force, doesn't strike as reason enough.  There
is so much else that differs between Plan 9 and NetBSD that I don't see
having different details of the semantics of union mounts as being a
particularly big deal.

(2) I can't say all that much about.  In general, I think flexibility
is good, but having changes occur at other than the top layer of a
union mount strikes me as a recipe for surprises (cf my comment about
renaming a file under another file).  I'd say it's worth experimenting
with - locally.  If those experiments indicate that it's a win, then
it's worth looking at putting it into the main tree.

> Don't be silly.

I don't think it's silly.  Slavish adherence to an system A's semantics
when working on system B, just for the sake of adherence that _does_
strike me as silly.  Maybe that's not actually what's going on here,
but that's what it looks like to me.  Perhaps I'm missing something.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B