Re: task-server hacking

[Marcus Brinkmann]

On Thu, May 22, 2003 at 04:57:53PM +0200, Niels Möller wrote:
> Marcus Brinkmann <address@hidden> writes:
> 
> > The rootserver is the only server privileged in L4.  So the rootserver will
> > do the following:
> [...]
> > The privileged calls will be done to the rootserver.  This all still has to
> > be written.
> 
> This sounds like a useless indirection to me.

I think you should reread my mail where I describe subsystems.
 
> We'd have
> 
>   root server: Wrapper interface for the privileged system calls
>   (including the ones needed by the task server), and restricted to
>   take requests only from the task server.

This is the meta-OS providing subsystem support.  This does not impose any
policy on subsystems.
 
>   task server: Accepts user tasks' requests, adds book-keeping,
>   accounting id:s and death notifications.

This is within each subsystem and provides new abstractions that go beyond
L4.  It also defines a lot of policy.

>   proc server: Keeps posix state about tasks, and access control for
>   interprocess interaction.

This is optional to use for tasks in the Hurd.
 
> Perhaps the task server (if it's small and lean enough) can be a
> module (and a few threads) loaded into the root server address space.
> That is, merge the first two layers. And you suggest merging the
> latter two ;-)

I only suggest merging the latter two because it could be faster and I am
too lazy to define a cool state of the art task<->proc interface.  But I
might change my mind, as communication between task and proc is trusted
(thus upcalls from task to proc can be blocking).
 
> Anyway, I think I'd prefer to have the code written as if it can use
> the privileged system calls directly, and if needed have stubs that
> direct those calls to the right root server thread instead.

Of course that's how it will be done.  The worst that might happen is that
you need a slightly different function name and an initial argument.

Note that only the first couple of threads in the subsystem is privileged
(one per cpu), so the task and physical memory server need to be implemented
in the same task.
 
> > I think we want to use IDL for that server already, and possibly handles.
> > As to the detail of sednign messages and such, I am still playing with that
> > myself.  The first pager I wrote didn't work for some reason :)
> 
> I haven't looked into the IDL alternatives at all yet. For hurd
> servers, I think we want an IDL that understands handles and the
> handle transfer protocols. Writing a few servers by hand should be a
> good way to figure out what code the IDL processor process and
> generate.

The task server is a Hurd server.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    address@hidden
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
address@hidden
http://www.marcus-brinkmann.de/