Hi,
Have a look at the description of DDEKit architecture from Björn Döbel, a
designer of DDE/Linux.
It seems that the design of DDE/Linux is quite nice (see below), which makes
porting and later maintenance much easier.
I read DDEKit. It doesn't have much code and most code can be ported easily.
There is something I have to implement myself, such as semaphore and slab
cache. I believe implementing these two will occupy most of my time in porting
DDEKit.
Zheng Da
-------- Original Message --------
Subject: Re: ddekit and dde linux2.6
Date: Sat, 21 Nov 2009 19:38:05 +0100
From: Björn Döbel <doe...@os.inf.tu-dresden.de>
To: Zheng Da <zhengda1...@gmail.com>, L4 Hackers
<l4-hack...@os.inf.tu-dresden.de>
References: <4b07fbf0.2060...@gmail.com>
<4b080df2.2030...@os.inf.tu-dresden.de>
<537a6f690911210836r6a905c5fr6c9b5dec2a112...@mail.gmail.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
> 2009/11/21 Björn Döbel <doe...@os.inf.tu-dresden.de>:
>>> It seems that ddekit is still under active development. What is its current
>>> development status?
>> DDE/Linux 2.6 is supporting Linux 2.6.29 drivers at the moment. The
>> DDEKit has been developed in parallel along with our experimental
>> setups, which include network drivers (you might have a look at
>> l4/pkg/ore) and USB (see l4/pkg/usb), as well as some experimental hard
>> disk stuff which is not in the SVN.
>
> I suppose DDEKit allows us to build and run any Linux drivers without
> modification. Why do we still need to make some effort to port drivers
> to DDEKit? Do I miss something?
There is no need to port any driver to DDEKit. In the beginning you have
the following problem: your driver wants a Linux interface to run and
your OS is providing a different one:
+--------------+
| L4 I/O layer |
+\ +----\ /+
\-/ \-/
/+\
+-/ \--------+
| Linux driver |
+--------------+
To make the Linux driver run on your target OS, you need to provide a
glue layer that is mapping the Linux driver calls to your target OS.
This is what the DDE (device driver environment) is good for.
+--------------+
| L4 I/O layer |
+\ +----\ /+
| \-/ \-/ |
| DDE |
| |
| /+\ |
+-/ \--------+
| Linux driver |
+--------------+
Now you have another problem if you want to support not only Linux
drivers but also the ones from *BSD or any other source. You'd need to
rewrite the DDE glue library for each of these. The idea of the DDEKit
is now to provide a generic driver abstraction layer so that
implementing the higher-level DDE/{Linux,FreeBSD} becomes easier.
+---------------+
| L4 I/O layer |
+\ +----\ /-+
| \-/ \-/ |
| DDEKit |
| |
+---------------+
^
|
+-----------------------------+
| |
+---------------+ +----------------+
| /+\ DDE/Linux| | DDE/FBSD /\ /-\|
+-/ \---------+ +---------/ + \
| Linux driver | | FreeBSD driver |
+---------------+ +----------------+
Note, that all the DDE/* libs use only those functions provided by the
DDEKit. This has another advantage. You port DDEKit to a new target OS
(e.g., the hurd in your case) and you get all the available DDEs to run
on top for free.
So to get back to your question. You don't port any device driver. You
just link it against the corresponding DDE library and don't do any
modifications. The plan is that this works for all drivers. However,
each device driver class uses some different subsystems and when you
start running a new driver from a not-yet supported class, it may happen
that you need to add functionality to the DDE. We're pretty sure that we
have enough support for USB and network drivers and we also have more or
less working block and sound drivers. If your goal is to run one of
these drivers, you should be ready to go. If you want something else,
there may be the need to add functionality to the respective DDE, not to
DDEKit.
I hope that made this clearer?
Bjoern
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEUEARECAAYFAksIM40ACgkQP5ijxgQLUNmBLQCY59ID3ngN0I4kByjuSjcXxK0j
agCeJqwwhcB5iYANDWn/dRGiDhBxHBI=
=WPW7
-----END PGP SIGNATURE-----
