From mboxrd@z Thu Jan  1 00:00:00 1970
From: erik quanstrom <quanstro@quanstro.net>
Date: Sat,  5 Dec 2009 08:51:52 -0500
To: 9fans@9fans.net
Message-ID: <099b51cd45f34f06a964675ee992bb92@brasstown.quanstro.net>
In-Reply-To: <<20091205081032.GJ8759@nipl.net>>
References: <<20091205081032.GJ8759@nipl.net>>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] ideas for helpful system io functions
Topicbox-Message-UUID: a849cb64-ead5-11e9-9d60-3106f5b1d025

On Sat Dec  5 03:11:09 EST 2009, sam@nipl.net wrote:
> > the standard way of passing file descriptors is by fork/exec.
> > this allows security is handled by the normal means.
>
> Erik/others, would you please give some feedback on my idea (a join call which
> connects two fds together and disowns them from the process).  Passing fds
> around does not solve the same problems and has nothing to do with what I
> suggested.
>
> Perhaps this list is not the right place to air "new" or different ideas
> related to the implementation of operating systems?

the problem with syscalls is (as we see in linux and before them
berkeley), it is realatively easy to think of a special case for which
a specialized system call would be just the ticket.

the set of all these special cases is quite large. and since the goal
of plan 9 is to be a (relatively) general purpose operating system
that can be understood by a single person, and well-maintained
by a small group, one needs a pretty compelling case for a new
system call.

further, system calls are by definition tied to the machine the call
was made on.  system calls live outside the namespace.  i would
first think about doing this as a kernel file server.  but it seems
to me there are security concerns.

i don't yet see that a compelling case has been made for a new
system call or even a kernel fileserver.  a real world (working)
example and a demonstration of why existing mechanisms
fall short would be helpful.

- erik