If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Device driver environment

A couple of things I was wondering about your DDE - have you made any attempt at getting other small OS projects to make use of it too, so as to spread maintenance and testing work? And have you tried getting changes into the Linux kernel to make drivers work more easily with your DDE? I know that the Linux people have traditionally been rather averse to the idea of sharing driver code with other OSes, but perhaps they would not mind as long as they are the upstream and the changes didn't adversely affect the Linux kernel (it would provide additional testing of their kernel driver code too).

A couple of things I was wondering about your DDE - have you made any attempt at getting other small OS projects to make use of it too, so as to spread maintenance and testing work? And have you tried getting changes into the Linux kernel to make drivers work more easily with your DDE? I know that the Linux people have traditionally been rather averse to the idea of sharing driver code with other OSes, but perhaps they would not mind as long as they are the upstream and the changes didn't adversely affect the Linux kernel (it would provide additional testing of their kernel driver code too).

I'm an interested user not a developer of Genode but from I understand pf it the device drivers work in user space not kernel space so it might not be that useful to linux. I don't think linux developers have any problem with sharing driver code with any other GPL project.

I'm an interested user not a developer of Genode but from I understand pf it the device drivers work in user space not kernel space so it might not be that useful to linux.

It will be useful (or not) to Linux only insofar as it provides additional test coverage. Regarding user space and kernel space, code and the way it works is largely independent of which of those two it runs in. Generally the main difference is that compiled kernel space code can execute certain privileged machine instructions which will cause an exception if user space code tries to execute them. However, these tend to be abstracted out of the source code in Linux drivers, as they are different on each CPU architecture the driver will run on anyway, and from that point of view the DDE probably acts as something similar to a new architecture. And of course the set of APIs available to code tend to be very different in user and kernel space, but the whole purpose of the DDE is to hide those differences.

The sort of changes I was thinking of when I talked about submitting upstream were more little fiddly things such as changing a driver not to use a kernel API which it doesn't really have to, so that there is one API less to be implemented in the DDE.

Because DDE is the glue between Linux code and Genode, the code is specific to both Genode and Linux. However, the code can be classified into two different groups.

First, there is code that handles the driver's access to hardware (such as memory-mapped I/O, interrupts, or port I/O). We have indeed a Genode-agnostic API (called DDE kit) for this part. The implementation of DDE kit is Genode-specific but the API is generic. Hence, the part of DDE that translates drivers code to DDE-kit calls is quite independent from Genode and could be subject to be ported to other small OSes.

The second part is the code that integrates the high-level driver API with Genode. This code is inherently tied to Genode.

With our new DDE for the USB stack, we have not attempted to separate both classes functionality. Our main concern was to keep the DDE as small as possible. But when looking at the code complexity of the new (USB-specific) DDE of less than 4.000 lines of code, I think there is not much of a point in introducing abstraction layers in there.

The DDE approach was first implemented by TU Dresden in the TUD:OS research OS. This version was later ported to Minix3 and HURD (and also to the Linux userland, btw). So the general approach to device-driver reuse has been adapted by several groups. There is no centrally managed project though. As explained in the release notes, however, we abandoned the original approach of DDE because it turned out to be hard to maintain and to debug. We are much more confident in our new methodology.

Regarding the question on proposing changes to upstream Linux, I am quite happy that the days when we needed to modify the Linux code are over. The new DDE approach completely eliminates the need for such modifications.

The sort of changes I was thinking of when I talked about submitting upstream were more little fiddly things such as changing a driver not to use a kernel API which it doesn't really have to, so that there is one API less to be implemented in the DDE.

That is hard to tell. On the course of constructing the DDE for USB, it becomes apparent that the breadth of the kernel interface referenced by the driver is indeed staggering. Of those functions, however, only a fraction is actually called in our scenario. The list of dummy functions (see dummies.c) is quite telling. All of those functions are somehow called by the driver at some point when used in the Linux kernel. But not in our scenario where we have limited the scope to USB storage and USB HID. Many of the functions are related to code paths that we just don't trigger (i.e., those related to Linux-specific bureaucracy needed to integrate the driver with the Linux kernel, functions specific for power management, or different classes of USB devices). At this point, I find it hard to identify improvements substantial enough to justify a discussion with the Linux kernel developers. Of course, if we found show stoppers or bugs, this would be a different story. But we haven't so far.