From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <79def6aa849a790de3969329762f0b23@quanstro.net>
From: erik quanstrom <quanstro@quanstro.net>
Date: Sun,  4 Jan 2009 12:32:41 -0500
To: 9fans@9fans.net
In-Reply-To: <20090104061045.GJ8355@masters10.cs.jhu.edu>
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: 78828f66-ead4-11e9-9d60-3106f5b1d025

> Constructing a namespace without RFNOMNT that does not have #s (say) bound
> is not really securing #s (and its other consumers) against that namespace's
> actions.  Constructing a namespace with RFNOMNT and without #s bound does
> at least two bad things:
>   -> it makes it impossible to pass fds around between processes in this
>      namespace, as there is now no /srv backing.
>   -> it prohibits import of additional resources.

i think you've got the cart before the horse.
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.

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.

with that in hand, it then would make sense
to talk about second-order problems.

- erik