L4Linux update? Driver support
adam at os.inf.tu-dresden.de
Wed Nov 4 00:22:44 CET 2015
On Tue Nov 03, 2015 at 15:30:37 +0100, ba_f wrote:
> Am 2015-11-03 00:08, schrieb Adam Lackorzynski:
> >On Mon Nov 02, 2015 at 18:20:55 +0100, ba_f wrote:
> >>Alrighty then,
> >>i guess i can back-port the stuff needed.
> >>Now, about Drivers:
> >>I want to write a L4Linux Driver that communicates with another L4-Task
> >>Can i just call all the L4-IPC stuff from within the driver?
> >You can but...
> >>Is there something special to take care of?
> >... take care that you use the L4XV_FN* wrappers and also do not block
> >long when doing calls because that will block L4Linux's vCPU. Best use
> >some asynchronous way of communication but at least make sure any calls
> >are replied soonish/immediately.
> Hey Adam & Folks,
> unfortunately, my Server does some crypto stuff and thus is pretty slow.
> Right now, my L4re-App (Client) is doing a IOStream::call() which i assume
> is not appropriate in L4Linux, since it's waiting long.
How long is long here? Couple of ms, or longer?
> So, L4Linux gets blocked with Istream::receive() and IRQ::receive(), right?
Receiving from an IRQ is actually pretty asynchronous, and you should
get IRQs the normal (L4)Linux way (do you?). A receive() operation is
> If this is true, i don't really see a clean way of an asynchronous
> communication, is there?
There are some options but all are more complicated than just doing
l4_ipc_call. Some common and good way is to use shared memory and
notifications to exchange data. When you do crypto, are you shuffling
data around and maybe already have some shared memory? Alternatively,
your server could have some submit+fetch interface, with polling or even
a notification via an interrupt. Although this last one scores better on
the hacky-scale it should be faster to implement :)
Adam adam at os.inf.tu-dresden.de
More information about the l4-hackers