Re: L4Linux update? Driver support

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