> > Put another way: you always have "send-rights" to any "port" that is
> > listening to messages.
>
> What establishes the existence of a port?
Actually, what is meant is that any L4 task can initiate IPC to any
other L4 task, if it nows the tid (task id). L4 has a hierarchical
"Clans and Chiefs" security model which causes any interclan
communication to be routed through the chiefs, so that can be used to
restrict communications.
L4 IPC is synchronous and unbuffered. Task A does a send IPC to B, and
nothing happens until it either times out, or task B does a
corresponding receive. I think that maybe the receive has to be
initiated first as well. I'll have to check on that.
There is no notion of a port or send-rights. Those are things we would
have to create on the userlevel somehow. I hope we can find a clever way
to implement it without having to do data copying. It might be possible
to pass the data through a traffic server (task's chief?) without
copying. One bonus is that the same structure used for send descriptors
can be used for the corresponding receive, so you can avoid copying in
that manner.
> What prevents people from sending messages to ports when they
> shouldn't be allowed to?
This would have to be implemented in the security model somehow.
Currently, "Clans and Chiefs" is the security model. It is supposed to
be revised in the next version of L4, for which details have yet to be
released. Until they are, I think we should work with what we have.
> > 1. The only entity that is allowed to hand out TIDs (a.k.a ports) to
> > clients will be a user-land port-rights server task. (pr-server).
>
> Expensive I would expect. Isn't that a whole nother two context
> switches everytime a port is created?
It would be, but there is no notion of ports in the kernel. No kernel
structures are used for IPC (aside from timeout monitoring and such).
The good news is that context switches on L4 are very fast, orders of
magnitude faster than with Mach. It was a design goal of the system.
Rather than try to design systems which avoid context switches, find a
way to make the context switches cheap. There are papers describing this
available on the Fiasco site.
> Something already needs to keep track of process death anyway, so if
> L4 doesn't provide that, whatever does can clean the ports too.
This must be the way. I took a quick look over the L4 manuals to try to
find a way to be notified of task death, but I didn't see anything
obvious. There must be some sort of notification involved though, right?
-- Ian
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Ian Duggan [EMAIL PROTECTED]
http://www.ianduggan.net
_______________________________________________
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
