> 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. _______________________________________________ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd