Hello,
2009/11/22 Björn Döbel doebel@os.inf.tu-dresden.de:
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.
I'm really happy to hear that:-)
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?
Yes, thank you very much for your explanation. I am also very happy to hear that new functionalities are added to DDE instead of DDEKit. It really makes the maintenance work in the future much easier. Good design:-)
Zheng Da