ddekit and dde linux2.6

[Zheng Da]

Hello,

2009/11/22 Björn Döbel <doebel at 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