Hi Björn!
Why do you need Linux functions to do L4 IPC?
We need them, because we want to provide (L4)Linux kernel features to other L4/L4Linux tasks.
Sleeping in IPC in an IRQ context works. Have a look at
drivers/net/l4ore.c - this is a
network driver interfacing the ORe network server. It runs in IRQ context
and does
blocking IPC to an external server.
Yes, but that's the other way round - that's already working. I was talking about the IPC-*Server* side where you might run into a *Linux* function that wants to go into *Linux* sleep which normally causes scheduling within Linux.
This is a known limitation of the L4v2 API and there are many packages in
the L4 tree that
handle these situations, for instance l4/pkg/l4vfs/term_server, and
l4/pkg/ore. Yes, I know that. I also described a way how it can be handled. What I was asking for, was *another* way, a simpler way of solving this problem.
AFAIR there is a discussion (or even more) about "separated" IPC where some arbitrary thread of a task may reply to an incoming IPC to another thread of that task.
Regards Oskar.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi again,
Why do you need Linux functions to do L4 IPC?
We need them, because we want to provide (L4)Linux kernel features to other L4/L4Linux tasks.
And why do you need to run the server thread in an IRQ context? Couldn't it just be a "normal" L4Linux thread?
Bjoern
Hi!
And why do you need to run the server thread in an IRQ context? Couldn't it just be a "normal" L4Linux thread?
That exactly was my question. The server thread must run within the L4Linux kernel. I only know how to create Linux threads which are not capable of providing IPC server services due to blocking, and I know L4Linux threads that run in IRQ contexts. Is there another way?
Best Oskar.
l4-hackers@os.inf.tu-dresden.de