L4Linux update? Driver support
ba_f
ba_f at rbg.informatik.tu-darmstadt.de
Mon Nov 16 17:22:05 CET 2015
Hello,
Am 2015-11-04 00:22, schrieb Adam Lackorzynski:
> Hi,
>
> 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:
>> >>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.
Can you be a bit more precise on this, please.
What's the problem with L4Linux's vCPU blocking long?
Does it crash, or is it just that all L4Linux threads get blocked as
well?
A colleague of mine suggested that all L4Linux threads are automatically
pushed into its own tasks, anyway, and such would not be affected by one
blocking thread.
Is this true?
>> unfortunately, my Server does some crypto stuff and thus is pretty
>> slow.
>
> How long is long here? Couple of ms, or longer?
Some operations definitely take seconds.
>> 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?).
What do you mean by this?
Using on-chip interrupt controller? Or some kind of internal microkernel
IRQ?
If it is microkernel IRQ, i haven't figured out, yet, how to implement
this without blocking.
Is it possible? Are there examples?
> A receive() operation is
> indeed blocking.
>
>> 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 :)
Yes, i already have shared memory. Until now, I push its capability over
an IPC::call().
Cheers,
ba_f
More information about the l4-hackers
mailing list