At Tue, 19 Jun 2007 20:26:05 -0700,
Thomas Bushnell BSG wrote:
> > On 6/20/07, Neal H. Walfield <[EMAIL PROTECTED]> wrote:
> >
> > > (1) Add a set of new environment variables, e.g.
> > PFINETSERVER for the pf_inet server and PFLOCALSERVER for the
> > pf_local server.
> >
> > We should have consistent naming between node names and
> > environment variables. The default node names
> > are /servers/socket/{2,pfinet}, etc. Perhaps have
> > SERVERS_SOCKET_PFINET be the name of the environment variable
> > to use.
>
> I wonder how you plan to implement this. The library does not use
> the #define symbol in practice; it uses /servers/socket/%d and fills in
> %d from the first argument to the socket() call.
Good point.
> It seems to me that an implementation which makes assumptions about how
> people construct names in /servers is unreliable.
These things are part of the system API, so I don't think it is so
unreliable. I think this is essentially what Roland says in this
message:
The io port allocation interfaces have to be
used on a well-known port location like /servers/ioperm because the name
goes into libc's implementation of the ioperm function. It doesn't hurt
for that to be a symlink to some other /servers or /dev node if there is a
single server doing several things. The important point is that what nodes
to use as the public interface for a system-wide facility is an interface
choice, and how many different servers actually control which interface
nodes is an implementation and policy choice.
http://www.mail-archive.com/bug-hurd@gnu.org/msg14330.html
13 May 2007
> What about a different strategy, one more "hurdish"? For example, run
> the program in a pseudo-chroot which overrides the behavior of nodes
> inside /servers?
What is a pseudo-chroot?
I think what you are proposing is essentially filtering the global
name space via some fancy translator. When we are just interested in
overriding a small parts of the environment and the rest represents a
reasonable default, this may be fine. Such an approach is, however,
completely contrary to POLP. I think the right direction is private
name spaces, which can be achieved by passing capabilities. That was
the other part of my suggestion.
Neal
_______________________________________________
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd
