Hi,
I'm trying to understand ddekit and hopefully to port it to Hurd. It seems that ddekit is still under active development. What is its current development status? I read http://demo.tudos.org/dsweeper_tutorial.html, which said that new features such as hotplugging and power management would be added ddekit but it was in 2006. Have those features been added to ddekit? Is it possible for me to move the Linux USB driver on the top of dde without modification?
What is the status of dde linux2.6 (I mean the one in the directory l4/pkg/dde_linux26)? Is it still under development? Does it support the features I mentioned above?
Thank you, Zheng Da
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hello,
I'm trying to understand ddekit and hopefully to port it to Hurd.
good luck.
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 read http://demo.tudos.org/dsweeper_tutorial.html, which said that new features such as hotplugging and power management would be added ddekit but it was in 2006. Have those features been added to ddekit? Is it possible for me to move the Linux USB driver on the top of dde without modification?
USB hotplug worked the last time I looked.
Cheers, Bjoern
Hello
2009/11/21 Björn Döbel doebel@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?
Zheng Da
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
2009/11/21 Björn Döbel doebel@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
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
l4-hackers@os.inf.tu-dresden.de
-
Björn Döbel -
Da Zheng -
Zheng Da