Re: Do we want a server on `/servers/machine' (or similar)?

[Roland McGrath]

> Good.  Have such things been written down somewhere?

Probably not.

> Fine, but are you in fact suggesting to have separate server for i/o
> ports and memory access?  I would have stashed those two interfaces (as
> well as any others?) into one single server.

It doesn't matter deeply.  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.

There is no necessary intrinsic relationship between the io port and device
memory access facilities.  The traditional interface for applications on
other systems is the ioperm function and mmap on /dev/mem, which are not
tied together.

As long as the two facilities are actually doing independent things, there
is no special reason to do them in the same server.  For simple facilities
with canonical Unixoid access control, a simple ioperm delegation server on
/servers/ioperm and a simple memory mapping delegation server on /dev/mem
make sense to me.  (That is starting out mimicking the basic structure of
monolithic kernels' facilities for this.)  The latter might be implemented
as case of general libstore mapping to a microkernel device, adding an
access control by range feature if you want that.

In the long run, I imagine we'd have something more fancy.  That is,
unified access control for peripheral hardware resources so that a given
caller might be permitted exclusive access to one particular device,
encompassing its io ports, physical memory regions, and irqs.  But this
doesn't need to be designed now.