Hello,
I have managed to port DDE linux26 to the Hurd. At least it works with NIC drivers now.
A few problems: 1. dde linux26 doesn't support multiple PCI buses. Unfortunately, my virtual machine has two PCI buses: bus 0 and bus 2. Now I have to hardcode the bus numbers in the code. Do you have plan to support multiple PCI buses? 2. DDE Linux26 doesn't support sound card drivers.
Does DDE Linux26 support the block device and character device?
Zheng Da
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
I have managed to port DDE linux26 to the Hurd. At least it works with NIC drivers now.
Congratulations. :)
A few problems:
- dde linux26 doesn't support multiple PCI buses. Unfortunately, my virtual
machine has two PCI buses: bus 0 and bus 2. Now I have to hardcode the bus numbers in the code. Do you have plan to support multiple PCI buses?
Our approach is to provide the application with a single logical PCI bus within DDEKit and have a management component that parses the real PCI bus and multiplexes accesses. Have a look at l4/pkg/l4io. As in most of the cases you only use one device within a DDEKit-based application, we did not see any real benefit of supporting multiple PCI buses in DDE.
- DDE Linux26 doesn't support sound card drivers.
Does DDE Linux26 support the block device and character device?
The answer for all points is that this is usually a matter of adding the corresponding Linux code and maybe some glue code. We did this for character, sound and block devices to a certain point. However, there is no releasable code, yet.
Cheers, Bjoern
Hi,
On 10-1-27 下午8:03, Björn Döbel wrote:
I have managed to port DDE linux26 to the Hurd. At least it works with NIC drivers now.
Congratulations. :)
Thank you.
A few problems:
- dde linux26 doesn't support multiple PCI buses. Unfortunately, my virtual
machine has two PCI buses: bus 0 and bus 2. Now I have to hardcode the bus numbers in the code. Do you have plan to support multiple PCI buses?
Our approach is to provide the application with a single logical PCI bus within DDEKit and have a management component that parses the real PCI bus and multiplexes accesses. Have a look at l4/pkg/l4io. As in most of the cases you only use one device within a DDEKit-based application, we did not see any real benefit of supporting multiple PCI buses in DDE.
OK, I see your point and I believe that one device doesn't use two buses, but I didn't see how a logical PCI bus is mapped to a physical one. ddekit_pci_init calls err = l4io_pci_find_device(~0, ~0, start, &l4dev); to search for buses, which calls a RPC to the kernel, but every DDEKIT application starts with 0. I don't see where is your management component and how it chooses the right bus for the device.
- DDE Linux26 doesn't support sound card drivers.
Does DDE Linux26 support the block device and character device?
The answer for all points is that this is usually a matter of adding the corresponding Linux code and maybe some glue code. We did this for character, sound and block devices to a certain point. However, there is no releasable code, yet.
So are you still working on supporting character, sound and block devices?
Thank you, Zheng Da
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
- dde linux26 doesn't support multiple PCI buses. Unfortunately, my virtual
machine has two PCI buses: bus 0 and bus 2. Now I have to hardcode the bus numbers in the code. Do you have plan to support multiple PCI buses?
Our approach is to provide the application with a single logical PCI bus within DDEKit and have a management component that parses the real PCI bus and multiplexes accesses. Have a look at l4/pkg/l4io. As in most of the cases you only use one device within a DDEKit-based application, we did not see any real benefit of supporting multiple PCI buses in DDE.
OK, I see your point and I believe that one device doesn't use two buses, but I didn't see how a logical PCI bus is mapped to a physical one. ddekit_pci_init calls err = l4io_pci_find_device(~0, ~0, start, &l4dev); to search for buses, which calls a RPC to the kernel, but every DDEKIT application starts with 0. I don't see where is your management component and how it chooses the right bus for the device.
The L4IO server scans all PCI devices at startup. DDE applications use l4io_pci_find_device() to iterate over all the devices and assign them a local/logical PCI ID. So, yes, for a DDE application it always looks like there is only one PCI bus (bus 0) with a continuous range of devices.
- DDE Linux26 doesn't support sound card drivers.
Does DDE Linux26 support the block device and character device?
The answer for all points is that this is usually a matter of adding the corresponding Linux code and maybe some glue code. We did this for character, sound and block devices to a certain point. However, there is no releasable code, yet.
So are you still working on supporting character, sound and block devices?
Yes. In our current (unreleased) versions, input devices work. Sound and block support has not been driven to an acceptible point, yet. There is also a USB package in the public SVN, fyi.
Bjoern
Hi,
On 10-1-27 下午8:51, Björn Döbel wrote:
- dde linux26 doesn't support multiple PCI buses. Unfortunately, my virtual
machine has two PCI buses: bus 0 and bus 2. Now I have to hardcode the bus numbers in the code. Do you have plan to support multiple PCI buses?
Our approach is to provide the application with a single logical PCI bus within DDEKit and have a management component that parses the real PCI bus and multiplexes accesses. Have a look at l4/pkg/l4io. As in most of the cases you only use one device within a DDEKit-based application, we did not see any real benefit of supporting multiple PCI buses in DDE.
OK, I see your point and I believe that one device doesn't use two buses, but I didn't see how a logical PCI bus is mapped to a physical one. ddekit_pci_init calls err = l4io_pci_find_device(~0, ~0, start, &l4dev); to search for buses, which calls a RPC to the kernel, but every DDEKIT application starts with 0. I don't see where is your management component and how it chooses the right bus for the device.
The L4IO server scans all PCI devices at startup. DDE applications use l4io_pci_find_device() to iterate over all the devices and assign them a local/logical PCI ID. So, yes, for a DDE application it always looks like there is only one PCI bus (bus 0) with a continuous range of devices.
You mean all devices in the system are in one logical bus, which can have at most 256*32 devices? It's a little odd, but should work fine. The current code of ddekit and dde linux26 obviously can only work in a system with one bus as the maximal number of pci devices in ddekit is 32.
- DDE Linux26 doesn't support sound card drivers.
Does DDE Linux26 support the block device and character device?
The answer for all points is that this is usually a matter of adding the corresponding Linux code and maybe some glue code. We did this for character, sound and block devices to a certain point. However, there is no releasable code, yet.
So are you still working on supporting character, sound and block devices?
Yes. In our current (unreleased) versions, input devices work. Sound and block support has not been driven to an acceptible point, yet. There is also a USB package in the public SVN, fyi.
I would like to know how well the current release of dde linux26 can support block devices and character devices as I want to try some devices other than NIC. For example, does it support SCSI disks? I see the USB package. Maybe I can try that since the Hurd doesn't have USB drivers yet.
Best regards, Zheng Da
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
The L4IO server scans all PCI devices at startup. DDE applications use l4io_pci_find_device() to iterate over all the devices and assign them a local/logical PCI ID. So, yes, for a DDE application it always looks like there is only one PCI bus (bus 0) with a continuous range of devices.
You mean all devices in the system are in one logical bus, which can have at most 256*32 devices? It's a little odd, but should work fine. The current code of ddekit and dde linux26 obviously can only work in a system with one bus as the maximal number of pci devices in ddekit is 32.
Yes, there is a physical limitation with the current approach. Our more recent ideas however go more into a direction where a physical IO manager provides applications with pre-configured virtual PCI buses, so that we did not really hit this limitation yet, because we provide for instance the NIC driver with a virtual PCI bus that only contains the NIC.
I would like to know how well the current release of dde linux26 can support block devices and character devices as I want to try some devices other than NIC. For example, does it support SCSI disks?
Not yet.
I see the USB package. Maybe I can try that since the Hurd doesn't have USB drivers yet.
Sure, good luck. ;)
Bjoern
Hi,
On 10-1-27 下午9:54, Björn Döbel wrote:
The L4IO server scans all PCI devices at startup. DDE applications use l4io_pci_find_device() to iterate over all the devices and assign them a local/logical PCI ID. So, yes, for a DDE application it always looks like there is only one PCI bus (bus 0) with a continuous range of devices.
You mean all devices in the system are in one logical bus, which can have at most 256*32 devices? It's a little odd, but should work fine. The current code of ddekit and dde linux26 obviously can only work in a system with one bus as the maximal number of pci devices in ddekit is 32.
Yes, there is a physical limitation with the current approach. Our more recent ideas however go more into a direction where a physical IO manager provides applications with pre-configured virtual PCI buses, so that we did not really hit this limitation yet, because we provide for instance the NIC driver with a virtual PCI bus that only contains the NIC.
Who will interact with the physical IO manager? DDEKit or DDE Linux26? It seems the current DDEKit API doesn't allow DDE Linux26 to request that via DDEKit and DDEKit doesn't know what the device is.
Why do you not just put all PCI devices in the logical bus (so the number can be larger than 32)? There should be no physical limitation for the logical bus and the current limitation is set by DDEKit itself. Of course, then you have to change the code in DDE Linux26, so it can scan more than 32 devices on the logical bus until it finds the right one or there is no such device at all.
I would like to know how well the current release of dde linux26 can support block devices and character devices as I want to try some devices other than NIC. For example, does it support SCSI disks?
Not yet.
How about character devices? I hope some character devices can work now.
Best regards, Zheng Da
Hi,
On Wed, 27 Jan 2010 22:54:49 +0800 Da Zheng zhengda1936@gmail.com wrote:
Yes, there is a physical limitation with the current approach. Our more recent ideas however go more into a direction where a physical IO manager provides applications with pre-configured virtual PCI buses, so that we did not really hit this limitation yet, because we provide for instance the NIC driver with a virtual PCI bus that only contains the NIC.
...
Why do you not just put all PCI devices in the logical bus (so the number can be larger than 32)? There should be no physical limitation for the logical bus and the current limitation is set by DDEKit itself. Of course, then you have to change the code in DDE Linux26, so it can scan more than 32 devices on the logical bus until it finds the right one or there is no such device at all.
The main idea is to let each driver run as a separate application. Therefore applications using DDE usually do not need to access multiple devices and the virtual bus contains only one device in that case. Following this approach you would start multiple driver-servers (using DDE) if you need drivers for multiple devices. So instead of having one instance having 33 devices at its bus we would suggest to run 33 instances each having one device at the virtual bus.
regards, Henning
Hi,
On 10-1-28 下午6:01, Henning Schild wrote:
Yes, there is a physical limitation with the current approach. Our more recent ideas however go more into a direction where a physical IO manager provides applications with pre-configured virtual PCI buses, so that we did not really hit this limitation yet, because we provide for instance the NIC driver with a virtual PCI bus that only contains the NIC.
...
Why do you not just put all PCI devices in the logical bus (so the number can be larger than 32)? There should be no physical limitation for the logical bus and the current limitation is set by DDEKit itself. Of course, then you have to change the code in DDE Linux26, so it can scan more than 32 devices on the logical bus until it finds the right one or there is no such device at all.
The main idea is to let each driver run as a separate application. Therefore applications using DDE usually do not need to access multiple devices and the virtual bus contains only one device in that case. Following this approach you would start multiple driver-servers (using DDE) if you need drivers for multiple devices. So instead of having one instance having 33 devices at its bus we would suggest to run 33 instances each having one device at the virtual bus.
You missed my point. I understand that each driver runs in a separate program. The problem is that a device has to find the bus where it is located. In the current implementation, a driver can only scan 32 devices. If we have 33 devices in the system, its driver thinks there isn't such a device and fails to work.
So I suggest why not let the logical bus contains all devices in the system. Thus, the driver can always find its device no matter where the device is located, and we don't need an IO manager to pre-configure the logical PCI bus as Bjoern said, which seems quite complex.
By the way, does DDEKit treat a device with 2 functions as two logical devices or just one? The `func` of `ddekit_pci_dev` is always 0 and `ddekit_pci_find_device_fixed` only uses the argument `slot`. Either DDEKit treat a device with multiple functions as several logical devices or only one function in a device is exposed to DDE Linux26. Both seems not very reasonable.
Best regards, Zheng Da
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
You missed my point. I understand that each driver runs in a separate program. The problem is that a device has to find the bus where it is located. In the current implementation, a driver can only scan 32 devices. If we have 33 devices in the system, its driver thinks there isn't such a device and fails to work.
So I suggest why not let the logical bus contains all devices in the system.
Because in a secure system you don't want the NIC device driver to see all other devices. This is why we need an IO manager that manages access to devices on a per-driver basis.
Thus, the driver can always find its device no matter where the device is located, and we don't need an IO manager to pre-configure the logical PCI bus as Bjoern said, which seems quite complex.
By the way, does DDEKit treat a device with 2 functions as two logical devices or just one? The `func` of `ddekit_pci_dev` is always 0 and `ddekit_pci_find_device_fixed` only uses the argument `slot`. Either DDEKit treat a device with multiple functions as several logical devices or only one function in a device is exposed to DDE Linux26. Both seems not very reasonable.
Most probably we never stumbled over a multi-function device so far, so I'd consider this a bug rather than a reasonable decision. ;)
Bjoern
Hi,
On 10-1-28 下午9:39, Björn Döbel wrote:
You missed my point. I understand that each driver runs in a separate program. The problem is that a device has to find the bus where it is located. In the current implementation, a driver can only scan 32 devices. If we have 33 devices in the system, its driver thinks there isn't such a device and fails to work.
So I suggest why not let the logical bus contains all devices in the system.
Because in a secure system you don't want the NIC device driver to see all other devices. This is why we need an IO manager that manages access to devices on a per-driver basis.
I thought only root could run drivers.
Thus, the driver can always find its device no matter where the device is located, and we don't need an IO manager to pre-configure the logical PCI bus as Bjoern said, which seems quite complex.
By the way, does DDEKit treat a device with 2 functions as two logical devices or just one? The `func` of `ddekit_pci_dev` is always 0 and `ddekit_pci_find_device_fixed` only uses the argument `slot`. Either DDEKit treat a device with multiple functions as several logical devices or only one function in a device is exposed to DDE Linux26. Both seems not very reasonable.
Most probably we never stumbled over a multi-function device so far, so I'd consider this a bug rather than a reasonable decision. ;)
My VWare VM has multi-function devices. Though I don't really need to have drivers for them, I still have to take care of it. Otherwise, 32 slots in the logical bus are not enough.
I'm sorry to ask again about the status of DDE Linux26 again. The hard disk driver for TUDOS is based on DDE Linux26 or you wrote it from scratch? What about the graphic card since TUDOS already has graphic interface?
I also like to cc the letter to bug-hurd ML. Some people in the Hurd community are probably interested in the discussion.
Best regards, Zheng Da
Da Zheng, le Thu 28 Jan 2010 22:06:44 +0800, a écrit :
On 10-1-28 下午9:39, Björn Döbel wrote:
You missed my point. I understand that each driver runs in a separate program. The problem is that a device has to find the bus where it is located. In the current implementation, a driver can only scan 32 devices. If we have 33 devices in the system, its driver thinks there isn't such a device and fails to work.
So I suggest why not let the logical bus contains all devices in the system.
Because in a secure system you don't want the NIC device driver to see all other devices. This is why we need an IO manager that manages access to devices on a per-driver basis.
I thought only root could run drivers.
There is no strict architecture limitation (it doesn't even know what root is). Provided the kernel gives I/O permission to a task or projects MMI/O, the latter can run a driver.
Samuel
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
So I suggest why not let the logical bus contains all devices in the system.
Because in a secure system you don't want the NIC device driver to see all other devices. This is why we need an IO manager that manages access to devices on a per-driver basis.
I thought only root could run drivers.
No. Especially, since L4 does not have a concept of users, there is no super-user or anything. Access to hardware resources is granted by the kernel to any user app that has the corresponding rights.
I'm sorry to ask again about the status of DDE Linux26 again. The hard disk driver for TUDOS is based on DDE Linux26 or you wrote it from scratch?
It is DDE-based. Not very hard, you can extract libATA code from Linux and need to add a few function stubs the the L4-specific DDE glue.
What about the graphic card since TUDOS already has graphic interface?
TUDOS graphics are VGA-based, we don't use any hardware-accelerated driver there.
Cheers, Bjoern
Hi,
On 10-1-28 下午10:29, Björn Döbel wrote:
I'm sorry to ask again about the status of DDE Linux26 again. The hard disk driver for TUDOS is based on DDE Linux26 or you wrote it from scratch?
It is DDE-based. Not very hard, you can extract libATA code from Linux and need to add a few function stubs the the L4-specific DDE glue.
Is it possible for you to provide me the code? Since you have made it work, I don't want to redo it, and honestly, I'm probably not very good at it.
Thank you, Zheng Da
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10-1-28 下午10:29, Björn Döbel wrote:
I'm sorry to ask again about the status of DDE Linux26 again. The hard disk driver for TUDOS is based on DDE Linux26 or you wrote it from scratch?
It is DDE-based. Not very hard, you can extract libATA code from Linux and need to add a few function stubs the the L4-specific DDE glue.
Is it possible for you to provide me the code? Since you have made it work, I don't want to redo it, and honestly, I'm probably not very good at it.
I packed the disk server and started a wiki page: http://wiki.tudos.org/DDE::Windhoek
Feel free to download and contribute. ;)
Bjoern
On 10-1-29 上午12:05, Björn Döbel wrote:
I'm sorry to ask again about the status of DDE Linux26 again. The hard disk driver for TUDOS is based on DDE Linux26 or you wrote it from scratch?
It is DDE-based. Not very hard, you can extract libATA code from Linux and need to add a few function stubs the the L4-specific DDE glue.
Is it possible for you to provide me the code? Since you have made it work, I don't want to redo it, and honestly, I'm probably not very good at it.
I packed the disk server and started a wiki page: http://wiki.tudos.org/DDE::Windhoek
Feel free to download and contribute. ;)
Thank you. I'll try and see how well it can go.
Zheng Da
Hello,
On Thu, Jan 28, 2010 at 08:28:07PM +0800, Da Zheng wrote:
You missed my point. I understand that each driver runs in a separate program. The problem is that a device has to find the bus where it is located. In the current implementation, a driver can only scan 32 devices. If we have 33 devices in the system, its driver thinks there isn't such a device and fails to work.
Please, do not take the limitation to 32 devices for granted. It was just a reasonable guess at implemenation time and is power of 2.
So I suggest why not let the logical bus contains all devices in the system. Thus, the driver can always find its device no matter where the device is located, and we don't need an IO manager to pre-configure the logical PCI bus as Bjoern said, which seems quite complex.
I disagree here. In a modern OS you need access control and resource management also on driver level, as nobody wants his VGA driver mess with the USB host controller. The access policy to I/O resources in our design is implemented by a special system component. This component configures the virtual busses mentioned before, whereas each driver gets its own virtual bus, i.e., view on the real hardware. You may look into http://os.inf.tu-dresden.de/papers_ps/haenel-beleg.pdf. Lukas gives a good summary of our ideas in its Architecture section.
Regards
Hi,
On 10-1-29 下午7:37, Christian Helmuth wrote:
Hello,
On Thu, Jan 28, 2010 at 08:28:07PM +0800, Da Zheng wrote:
You missed my point. I understand that each driver runs in a separate program. The problem is that a device has to find the bus where it is located. In the current implementation, a driver can only scan 32 devices. If we have 33 devices in the system, its driver thinks there isn't such a device and fails to work.
Please, do not take the limitation to 32 devices for granted. It was just a reasonable guess at implemenation time and is power of 2.
The current implementation cannot work in my VMWare VM, which has more than 32 PCI devices, so I kind of hope it can be extended.
So I suggest why not let the logical bus contains all devices in the system. Thus, the driver can always find its device no matter where the device is located, and we don't need an IO manager to pre-configure the logical PCI bus as Bjoern said, which seems quite complex.
I disagree here. In a modern OS you need access control and resource management also on driver level, as nobody wants his VGA driver mess with the USB host controller. The access policy to I/O resources in our design is implemented by a special system component. This component configures the virtual busses mentioned before, whereas each driver gets its own virtual bus, i.e., view on the real hardware. You may look into http://os.inf.tu-dresden.de/papers_ps/haenel-beleg.pdf. Lukas gives a good summary of our ideas in its Architecture section.
I totally agree that we need to impose some access control and resource management. I just wanted to simply extend the current implementation. The current implementation doesn't have access control either, so I didn't consider the security issue.
Zheng Da
On 10-1-27 下午8:51, Björn Döbel wrote:
Yes. In our current (unreleased) versions, input devices work. Sound and block support has not been driven to an acceptible point, yet. There is also a USB package in the public SVN, fyi.
By the way, I forget to ask: how well can DDE FreeBSD support these devices? Is it still under development?
Best regards, Zheng Da
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Da Zheng wrote:
On 10-1-27 下午8:51, Björn Döbel wrote:
Yes. In our current (unreleased) versions, input devices work. Sound and block support has not been driven to an acceptible point, yet. There is also a USB package in the public SVN, fyi.
By the way, I forget to ask: how well can DDE FreeBSD support these devices? Is it still under development?
No idea. The DDE/FBSD work has been done to the point where it supported an ATA block device driver. So, probably you'd need to add more code if you wanted to run a BSD NIC driver with it.
Bjoern
On 10-1-27 下午9:52, Björn Döbel wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Da Zheng wrote:
On 10-1-27 下午8:51, Björn Döbel wrote:
Yes. In our current (unreleased) versions, input devices work. Sound and block support has not been driven to an acceptible point, yet. There is also a USB package in the public SVN, fyi.
By the way, I forget to ask: how well can DDE FreeBSD support these devices? Is it still under development?
No idea. The DDE/FBSD work has been done to the point where it supported an ATA block device driver. So, probably you'd need to add more code if you wanted to run a BSD NIC driver with it.
I take it as DDE/FBSD is only used to demonstrate the idea of DDE. I certainly don't want to develop it myself. I hope your group provide a relatively complete library to support all kinds of drivers, so I can make use of it:-) I think I just keep on DDE Linux26.
Best regards, Zheng Da
l4-hackers@os.inf.tu-dresden.de
-
Björn Döbel -
Christian Helmuth -
Da Zheng -
Henning Schild -
Samuel Thibault