[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Porting the Hurd to L4 (glibc dependencies, dropping glibc?)



My following remarks are concerned with porting the Hurd to L4 only; I
am not interested in a virtual kernel because of the performance
penalty and the general complexity of such a project, which will
decrease the probability of it ever bearing fruit.


>    -> If we don't use mach anymore (except via libvk-mach), what parts
>       of libports would be _really_ needed (architecturally)? This seems
>       like one of the most important porting decisions right now.
> 
It is.


>    -> At first sight (I didn't analyze the code in greater detail yet, so
>       I may be plain wrong here) libports _seems_ to hinder a lean
>       L4-style ipc thus adding a lot of ipc overhead which happens so
>       slow the Hurd down anyway. I'm I right to guess that libports
>       is mainly a hack to get an interface to the complex intricacies
>       of mach? How much of libports _is_ actually hurd, and how much
>       is mainly struggling with mach? I'd _really_ like to drop libports
>       on non-mach libvk hurd's if at all possible, or at least replace
>       it with a minimum non-mach subset.
> 
Ports, as I see them, are simply channels for communication between
processes.  They are identified by their ID (what else?) and protected
on both sides by their associated rights (at least, in mach).

A naieve way to implement this on L4 would be to give each task a
thread that handles all communication for its worker threads.  The
latter write to (or read from) ports that are presented to them by their
"communicator", which transforms the messages into "proper" L4 IPC
messages, putting the port ID into the first element of the payload. 
The receiving communicator unpacks the L4 payload and examines the port
ID to decide what to do with the port payload - mostly it will queue
the message for one of the worker threads in its task.  Note that the
communication between worker and communicator can be as asynchronous as
you want, and that the "port" ID is also used for authentication.

This scenario is almost certainly far too simple; I would be happy to
discuss this further in a more suitable list.  If one has already been
decided on, please tell me where and how to subscribe.


 Ad Buijsen
 



Reply to: