From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <5f971a06f85a460fe83f7571989845ba@proxima.alt.za>
To: 9fans@9fans.net
Date: Sun,  4 Jan 2009 20:23:01 +0200
From: lucio@proxima.alt.za
In-Reply-To: <79def6aa849a790de3969329762f0b23@quanstro.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] sendfd() on native Plan 9?
Topicbox-Message-UUID: 78a129b2-ead4-11e9-9d60-3106f5b1d025

> i haven't even seen what i think is a compelling
> argument for sendfd yet you're trying to argue
> for second-order problems with a particular
> application of sendfd.
>
Sendfd() seems to me a somewhat more carefully controlled version of
/srv.  As it stands, the additional features of sendfd() involving
security are not present in /srv, so one can make a case for providing
sendfd() (or a moral equivalent, as was originally suggested) in that
vacuum.  Enhancing /srv is certainly an option, but the exact
semantics aren't clear as sendfd() is quite remote from the Plan 9
style of implementing the analogous functionality.  While
investigating these semantics, Nathaniel merely identified how the
combination of #s and RFNOMNT falls short of the desired objectives.

> i would think that in order to justify sendfd one would
> need to
> - have a reasonable implementation of sendfd and
> - a useful application that needs it and can't be
> implented correctly without it.
> it would be more convincing with a paper
> that considers other options and makes the
> argument for sendfd.

I happen to agree with you, but Nathaniel originally specifically
asked how the sendfd() functionality could be achieved within the Plan
9 paradigm.  We have since digressed in a somewhat tortuous quest for
the exact requirements the Plan 9 design would need to satisfy.  We
are nowhere near a goal yet, because amongst all the discussion a lot
of effort has been expended in defending the Plan 9 way instead of
concentrating on how it could be enhanced.  Part of the problem is
that we do not clearly know which problem is being solved, the
objectives are still too vague and too caught up with what sendfd()
presently does.

Personally, I have a feeling that whittling down the objectives for a
sendfd() analogue would reveal that very little within Plan 9 actually
needs adjustment (a minor alternative to RFNOMNT, perhaps, or
factotum-like extensions to lock certain properties of #s).

The point is that this mailing list is a good a place to exchange
these ideas and some useful clarifications have already taken place.
I believe this discussion may be slow, but it is progressive.  If
enough people feel strongly about it, perhaps it ought to be taken
off-list, but I don't believe it should cease just yet (not that I'm
accusing anyone of shooting it down, but my comment may suggest that I
am).

++L