Re: DirectFB "Fusion" module inclusion?

[Alan Jenkins]

On 10/7/09, Niels Roest <niels@xxxxxxxxxxxx> wrote:
> Hi all.
>
> This is to request some comments about our interest to have our "Fusion"
> kernel module included in the kernel.
> I hope you will let me now if it is feasible, desirable, etcetera.

Possibly not.

> What is Fusion? Fusion is the low-level layer of DirectFB
> (www.directfb.org). DirectFB is basically a graphics library that offers
> hardware acceleration and multi-process cooperation on top of e.g. the
> frame buffer device.
>
> What does Fusion offer? Fusion takes care of IPC by providing the
> following primitives: skirmishes (locks), calls (partially via a
> user-space library handling callback threads), properties and shared
> memory pools. The main two reasons for us to make a kernel module out of
> this is: crashing applications will not take down the "DirectFB" system,
> since resources are handled in the kernel; and debug
> information/deadlock status is shared via /proc/fusion.
>
> Fusion documentation (fusion.pdf) can be found at
> http://git.directfb.org/?p=core/linux-fusion.git;a=tree;f=doc;
> Fusion source files can be found at the same git location:
> http://git.directfb.org/?p=core/linux-fusion.git;a=tree
>
> Fusion is implemented as a device driver with an ioctl interface. In our
> case, Fusion is used together with libfusion.so (LGPL), which abstracts
> the kernel ioctls away, among other things. DirectFB resides on top of
> libfusion.so.
>
> We would probably rework Fusion significantly if needed - we want to
> have the benefit of having Fusion inside kernel mainline, and we hope
> that it is indeed interesting enough to consider, so let's hear it :)

I do have some suggestions.  These carry no weight or guarantee of
acceptance, they are simply my impressions as a slightly curious
bystander.

I believe the ioctls would have to be replaced with system calls.

The easy example is shared memory.  We already have mmap() to map it,
and ftruncate() to increase the size of the memory region; you just
need to provide a way to obtain a file descriptor.

Similarly we already have sockets.  We don't have RPCs per se; but it
seems to be covered by sending formatted "call" and "return" messages
over sockets.  It looks like unix domain sockets would work already.

Refs and reactors have no obvious parallels.  You get to defend the
utility of the system calls and possibly other ABIs you need in order
to implement them, or find less novel alternatives which can be made
to work.  It may be possible to implement refs in userspace using
shared memory and futexes.  If so, make sure you read the paper which
describes the pitfalls encountered when implementing pthread mutexes
using futexes :-).  Reactors are tricky; they might be accepted as a
new socket type, or perhaps implemented using new socket options.

Then you want to tie them all together with a common namespace.  This
is commonly known as a filesystem :-P.  Top level directory defines
the "world"; the second level directory gives you the "fusion ID".
Ideally you've avoided adding a new type of filesystem node so you can
use an arbitrary filesystem.  I believe tmpfs is already used as the
standard backing store for posix shared memory.

I guess you can block on world (directory) creation using inotify.

For debugging information you will probably have to create a new
filesystem.  You're not allowed to shove everything in procfs anymore
:-).

BTW, your /proc documentation includes "properties" but they don't
seem to be mentioned any where else.

Regards
Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/