Hi All,
I’m new to L4Fiasco and L4Linux. I’ve managed to build and run L4Linux 2.6.28 using dope (thanks to this mail list). In the next step I would like to remove as much as possible hardware access operations from L4Linux to L4 servers. By splitting L4Linux driver into two parts, first one is the L4Linux stub driver which talks to second L4 server part which in its turn has a deal with access to hardware. Any form of multiplexing/demultiplexing of hardware between several L4Linux instances is not required at this stage, only monopolistic access. Actually, the ideal solution for me is where L4Linux doesn’t have direct access to hardware at all.
I have some questions to community: 1. Is it generally possible? 2. What kind of native L4 or DDE drivers are available now? And what about corresponding stub drivers for L4Linux? 3. How should I configure L4Linux or maybe packages in /trunk/l4/pkg/ to remove as much as possible hardware access operations from L4Linux to L4 servers? Are there any ready-to-use L4Linux "config" files for this purpose?
Thank you in advance.
Best Regards, Alexander Valitov
Hi,
On Thu Feb 05, 2009 at 06:24:21 -0800, Alexander Valitov wrote:
I’m new to L4Fiasco and L4Linux. I’ve managed to build and run L4Linux 2.6.28 using dope (thanks to this mail list). In the next step I would like to remove as much as possible hardware access operations from L4Linux to L4 servers. By splitting L4Linux driver into two parts, first one is the L4Linux stub driver which talks to second L4 server part which in its turn has a deal with access to hardware. Any form of multiplexing/demultiplexing of hardware between several L4Linux instances is not required at this stage, only monopolistic access. Actually, the ideal solution for me is where L4Linux doesn’t have direct access to hardware at all.
I have some questions to community:
- Is it generally possible?
Yes, this is one of the premium use cases.
- What kind of native L4 or DDE drivers are available now? And what about
corresponding stub drivers for L4Linux?
There's ORe, which is a network stack in software and a corresponding network driver in L4Linux. There a pseudo serial driver in L4Linux. There's a block stub but currently without a real L4 driver. Then the framebuffer driver that talks to l4con and dope. Same for input.
- How should I configure L4Linux or maybe packages in /trunk/l4/pkg/ to
remove as much as possible hardware access operations from L4Linux to L4 servers? Are there any ready-to-use L4Linux "config" files for this purpose?
The UX configuration is without any hardware drivers: make x86-ux_defconfig should give a good start. There isn't any particular configuration you need to do for the L4 packages.
Adam
Hi Adam,
Thank you for prompt answer.
I think I have found all L4Linux configuration options related to my task in the following menuconfig’s menu:
L4Linux configuration -> Stub drivers ->
Here they are (I put corresponding variable in parentheses):
[*] Use the rtc server (L4_EXTERNAL_RTC) [ ] Block driver for the generic_blk interface (L4_BLK_DRV) [ ] Block driver for the persistent dataspace interface (L4_PDSPBLK_DRV) [*] Framebuffer driver for l4con and DOpE (input/output) (L4_FB_DRIVER) [ ] Support for the X Window System driver (L4_FB_DRIVER_XF86IF) [ ] Network driver for ORe (L4_ORE_DRV) [*] Pseudo serial driver for console (L4_SERIAL) [*] Serial console support (L4_SERIAL_CONSOLE) [ ] Cons system support (L4_CONS)
Meaning of some of these options is clear for me and some of them isn’t. If I’m right:
1. L4_EXTERNAL_RTC option forces L4Linux to use rtc module instead of direct access to timer hardware. 2. As you wrote L4_FB_DRIVER compiles in l4fb module into L4Linux, so it could be used by dope or con server. 3. L4_ORE_DRV adds stub network driver to L4Linux which uses ore server for actual access to NIC.
Other isn’t really clear:
1. Help in menuconfig says L4_SERIAL : "Serial type driver used for console". L4_SERIAL_CONSOLE : "you will be able to use the pseudo serial interface as a system console"
I can’t get the difference between L4_SERIAL and L4_SERIAL_CONSOLE options. Maybe L4_SERIAL is pseudo COM port driver and L4_SERIAL_CONSOLE is module for system console (I mean ttyLv0). Am I right here?
2. Another confusing thing is that Wiki says console=ttyLv0 options is to use 'l4ser' driver for console. But I don’t load such a module (l4ser) and 'console=ttyLv0' option works. What is 'l4ser'? Is it L4 server? If it's not who controls COM port hardware? Is it done by L4 kernel?
3. You've mentioned "block stub without a real L4 driver". Is it L4_BLK_DRV? Do you have plans to implement the L4 driver?
4. Unfortunately, menuconfig help isn't really comprehensible for me. Could you please explain, in short, what is L4_CONS?
5. And L4_PDSPBLK_DRV?
6. And L4_FB_DRIVER_XF86IF?
Best Regards, Alexander Valitov
Hi Alex,
On Fri Feb 06, 2009 at 08:05:56 -0800, Alexander Valitov wrote:
I think I have found all L4Linux configuration options related to my task in the following menuconfig’s menu:
L4Linux configuration -> Stub drivers ->
Here they are (I put corresponding variable in parentheses):
[*] Use the rtc server (L4_EXTERNAL_RTC) [ ] Block driver for the generic_blk interface (L4_BLK_DRV) [ ] Block driver for the persistent dataspace interface (L4_PDSPBLK_DRV) [*] Framebuffer driver for l4con and DOpE (input/output) (L4_FB_DRIVER) [ ] Support for the X Window System driver (L4_FB_DRIVER_XF86IF) [ ] Network driver for ORe (L4_ORE_DRV) [*] Pseudo serial driver for console (L4_SERIAL) [*] Serial console support (L4_SERIAL_CONSOLE) [ ] Cons system support (L4_CONS)
Meaning of some of these options is clear for me and some of them isn’t. If I’m right:
- L4_EXTERNAL_RTC option forces L4Linux to use rtc module instead of direct
access to timer hardware.
Yes.
- As you wrote L4_FB_DRIVER compiles in l4fb module into L4Linux, so it
could be used by dope or con server.
Yes.
- L4_ORE_DRV adds stub network driver to L4Linux which uses ore server for
actual access to NIC.
Yes. Or for communication with other Ore clients, like other L4Linuxes.
Other isn’t really clear:
- Help in menuconfig says L4_SERIAL : "Serial type driver used for console". L4_SERIAL_CONSOLE : "you will be able to use the pseudo serial interface as
a system console"
I can’t get the difference between L4_SERIAL and L4_SERIAL_CONSOLE options. Maybe L4_SERIAL is pseudo COM port driver and L4_SERIAL_CONSOLE is module for system console (I mean ttyLv0). Am I right here?
Yes, basically. It's the same difference as e.g. SERIAL_8250 and SERIAL_8250_CONSOLE. I.e. with *_CONSOLE one can use the driver as a system console.
- Another confusing thing is that Wiki says console=ttyLv0 options is to
use 'l4ser' driver for console. But I don’t load such a module (l4ser) and 'console=ttyLv0' option works. What is 'l4ser'? Is it L4 server? If it's not who controls COM port hardware? Is it done by L4 kernel?
l4ser is the serial driver, i.e. the one behind L4_SERIAL.
- You've mentioned "block stub without a real L4 driver". Is it L4_BLK_DRV?
Yes.
Do you have plans to implement the L4 driver?
The old one for real disks hasn't been maintained for ages. Currently there's only one for Fiasco-UX which uses files on the host as disk images. It's in pkg/generic_blk/examples/ux.
- Unfortunately, menuconfig help isn't really comprehensible for me. Could
you please explain, in short, what is L4_CONS?
cons is some text-based console server which isn't in public svn.
- And L4_PDSPBLK_DRV?
It's block driver for a backend server that works on (memory) dataspaces.
- And L4_FB_DRIVER_XF86IF?
The counterpart to Xorg driver in the l4con package.
Adam
Hi Adam,
Adam Lackorzynski wrote:
- And L4_PDSPBLK_DRV?
It's block driver for a backend server that works on (memory) dataspaces.
Do you mean it is a kind of loop device which gives access to memory treating memory contents as a block device sectors? And memory is provided by dataspace manager with dm_mem or dm_generic interface? Is there corresponding L4 server available?
Adam Lackorzynski wrote:
- And L4_FB_DRIVER_XF86IF?
The counterpart to Xorg driver in the l4con package.
Is it needed to be turned on if I'd like to start X11 server when l4con or dope is used? Is it bridge between l4fb and X11 server?
There is another option that looks pretty interesting for me. It is CONFIG_L4_USE_L4VMM. I discovered it here: L4Linux configuration->Advanced options->Use L4VMM Help says: L4VMM can emulate hardware and provide access to virtual and physical host devices. For PCI, enable PCI support (choose direct access mode) and the required device drivers. Could you please tell me what is it intended for?
Alexander Valitov
On Mon Feb 16, 2009 at 08:09:01 -0800, Alexander Valitov wrote:
Adam Lackorzynski wrote:
- And L4_PDSPBLK_DRV?
It's block driver for a backend server that works on (memory) dataspaces.
Do you mean it is a kind of loop device which gives access to memory treating memory contents as a block device sectors? And memory is provided by dataspace manager with dm_mem or dm_generic interface?
Yes, basically. Block device backend storage is just memory.
Is there corresponding L4 server available?
No.
Adam Lackorzynski wrote:
- And L4_FB_DRIVER_XF86IF?
The counterpart to Xorg driver in the l4con package.
Is it needed to be turned on if I'd like to start X11 server when l4con or dope is used?
Depends. The easy method is just to use the fbdev driver in X11 and thus just use the (L4)Linux framebuffer. This has a few drawbacks like needed screen refreshs but works easily. The other one is to have an X server that knows the underlying system, i.e. has a special driver. This e.g. does not need refreshs but needs the special X driver.
Is it bridge between l4fb and X11 server?
Only if the X driver is used.
There is another option that looks pretty interesting for me. It is CONFIG_L4_USE_L4VMM. I discovered it here: L4Linux configuration->Advanced options->Use L4VMM Help says: L4VMM can emulate hardware and provide access to virtual and physical host devices. For PCI, enable PCI support (choose direct access mode) and the required device drivers. Could you please tell me what is it intended for?
It's for a very experimental service that virtualizes devices, e.g. a PCI bus or disk.
Adam
l4-hackers@os.inf.tu-dresden.de