From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <26d5e02ab7f78b72991a858f62d7bdbd@9srv.net>
From: a@9srv.net
To: 9fans@cse.psu.edu
Subject: Re: [9fans] 'wall' messages
In-Reply-To: <Pine.LNX.4.33.0310080819520.1216-100000@einstein.ssz.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Date: Wed,  8 Oct 2003 13:02:02 -0400
Content-Transfer-Encoding: quoted-printable
Topicbox-Message-UUID: 67b81d7a-eacc-11e9-9e20-41e7f4b1d025

// there should be -no- additional programming or commands for a user
// to do this.

on the part of the user, i assume you mean. otherwise it seem you'd
have to hope for it to magically apear. so you must be okay with some
programming on the part of , well, programmers, although it's
clearly desirable to minimize that, as well. kernel hacking is time
consuming and more dificult (at least to test and debug, if not to
write) than user-level code. so it seems like that'd be preferable,
if we can get what we want there. we'll see that we can in a minute.

// it needs to be available to all users, with the owner of the box
// where the hardware is resident being in control of the security.

the problem here is that there's more then one box involved, with
more than one owner. using the example at hand, if i cpu in to a
remote server, most (much?) of /dev is owned by me, parts by glenda
(and, ahem, none by bootes). so what gives the owner of the cpu
server the "right" to write to my devices? clearly, i need to be
able to allow the cpu server to, but that's *my* control. so i (or,
more likely, something acting on my behalf) needs to present to the
cpu server a way to get notices to me. default behavour should
always err on the side of too little sharing by default.

// since there are at least two filesystems that a cpu server can
// run native (ie kfs and fossil) it needs to be outside of those;
// ...That leaves only -one- place, the kernel.

falacy of false alternatives. "It can't be A so it must be B". The
correct initial response to such statements is almost *always*
"What about C?" (no pun intended). we've still not explained why
this can't be done in user mode ("i've seen it done!"). i come back
to the example of the plumber. the user does nothing to start it,
the user maintains controll of all the relevant resources, and
applications on multiple platforms communicate without knowing
anything about each other - just the plumber interface.

you seem to be under the impresion (especailly in your last
paragraph) that people are arguing that we shouldn't be allowed
to share resources. that's not at all what people are saying. we
just don't think kernel hacks to allow a privlidged user to get
access to a users's namespace - globally, generally - is any sort
of good idea.
=E3=82=A2