Anyways, minor question regarding the L4-Linux (or Fiasco for that matter) First off, I have some decent Compaq Pentium 1 desktops back home I could easily commandeer for hacking on. (I'm in college, so home is a 5 hour trip away) Will it run fine? I know system builds will suck, but it should work fine right? Secondly, I understand fully how a microkernel works, i've seen the schematics, flow charts, etc, but I'm confused at how a driver, for example, would be coded. Is it something that one hacks into userland? (Is it portable across L4 Operating Systems? (L4Linux, Fiasco, etc) Or does L4 have some special way of handling drivers? I know for example, that the Mach "microkernel" that Apple has bastardized for Darwin handles networking and such in the userland (it's been a while since i've played around on Darwin however) -Tyler ----------------- R. Tyler Ballance NetBSD-FreeBSD
On Tue Sep 14, 2004 at 08:44:30 -0700, R. Tyler Ballance wrote:
Anyways, minor question regarding the L4-Linux (or Fiasco for that matter)
First off, I have some decent Compaq Pentium 1 desktops back home I could easily commandeer for hacking on. (I'm in college, so home is a 5 hour trip away)
Will it run fine? I know system builds will suck, but it should work fine right?
Secondly, I understand fully how a microkernel works, i've seen the schematics, flow charts, etc, but I'm confused at how a driver, for example, would be coded. Is it something that one hacks into userland? (Is it portable across L4 Operating Systems? (L4Linux, Fiasco, etc)
Well, I wouldn't say "hacks" into user land, but they certainly do reside at userlevel. In short device drivers need a few things: 1/ Access to device registers 2/ Able to receive interrupts 3/ Abillity to perform DMA 4/ A way of ocmmunicating with the rest of the system 1/ is provided by mapping reigsters into your virtual address space. 2/ is provided by sending IPC mesages to a thread 3/ depends on your system setup, but basically requires a memory server that will provide memory pinning and v->p transalation 4/ is also highly system dependant, but you want access to network stack or filesystem etc. I've written at length about this in a thesis on device drivers in Mungi, a L4 based OS. (There is link on http://www.benno.id.au). As to portability, it depends. With the use of the right libraries and tools there is no reason why your driver can't be portable. At unsw we currently have drivers that are portable across arcitectures and run in L4, L4Linux, Mungi and as device drivers in the Linux kernel, and Linux user-level. (The code and docs fo this isn't released yet, but should be RSN. If you want more info please contact me off-list.) Cheers, Benno
On Tue Sep 14, 2004 at 08:44:30 -0700, R. Tyler Ballance wrote:
First off, I have some decent Compaq Pentium 1 desktops back home I could easily commandeer for hacking on. (I'm in college, so home is a 5 hour trip away)
Will it run fine? I know system builds will suck, but it should work fine right?
P1 boxes are supposed to work.
Secondly, I understand fully how a microkernel works, i've seen the schematics, flow charts, etc, but I'm confused at how a driver, for example, would be coded. Is it something that one hacks into userland? (Is it portable across L4 Operating Systems? (L4Linux, Fiasco, etc)
Drivers are in userland, yes (with the rights they need). Portable? Hmm, maybe you're mixing something up between Fiasco und L4Linux. Fiasco is an L4 kernel, L4Linux an L4 program running on a kernel. So L4Linux can contain drivers, or a driver can be a standalone L4 program offering the hardware functionality to clients. So a driver is more or less as portable as any other L4 program, i.e. depends on the used environment etc. Adam -- Adam adam@os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/
Hi all, I have a library that I load dynamically which uses __attribute__((constructor)) and __attribute__((destructor)). I compile the library with MODE=l4env which has compile option "-nostdlib". This disables the attributes and thus no initial and final code being executed when the library is loaded and unloaded. In fact all MODES has this option. Q1: Any suggestions how-to enable the con/destructor while keeping the MODE=l4env setting? Thanks Leon
Hi Leon, On Friday 17 September 2004 10:39, Leon wrote:
I have a library that I load dynamically which uses __attribute__((constructor)) and __attribute__((destructor)). I compile the library with MODE=l4env which has compile option "-nostdlib". This disables the attributes and thus no initial and final code being executed when the library is loaded and unloaded. In fact all MODES has this option.
That has nothing to do with -nostdlib. The program loader has to interpret the ctors/dtors section of the shared library.
Q1: Any suggestions how-to enable the con/destructor while keeping the MODE=l4env setting?
Static constructors/destructors are currently supported by the L4 loader. Note that shared library support of the L4 loader is very experimental. If you need static constructors/destructors you will have to switch to static libraries. Frank -- ## Dept. of Computer Science, Dresden University of Technology, Germany ## ## http://os.inf.tu-dresden.de/~fm3 ##
Hi all, I was informed that FLIPS currently only support the Intel eepro100 NIC. Q1: If FLIPS implements the DDE shouldn't it be possible to use any driver? Q2: If so where in the code would you configure FLIPS to use such a driver? Thanks Leon
Hello Leon, could you please write a new email (no reply) to l4-hackers@os.inf.tu-dresden.de in case you want to start a new thread. This a way it's easier to track which issue is discussed. On Fri, Sep 17, 2004 at 10:39:35AM +0200, Leon wrote:
Hi all,
I was informed that FLIPS currently only support the Intel eepro100 NIC.
Q1: If FLIPS implements the DDE shouldn't it be possible to use any driver?
To tell the truth, FLIPS does not really "support" eepro100 NICs. FLIPS is a port of the Linux 2.4 TCP/IP stack to L4. "flips-lxdrv" is just a simple toy to get it working on real hardware - my test box. You are free to hack other drivers into flips/server/lib-lxdrv. There exists a package that uses dde_linux to run Linux NIC drivers on L4, but unfortunately it's not in our public CVS up to now.
Q2: If so where in the code would you configure FLIPS to use such a driver?
(see above) I think you have to hack a bit to get it running. Which NIC do you want to use (Linux driver file)? Maybe I could help you. Chao -- Christian Helmuth ## Dept. of CS, TU Dresden, Germany ## ## http://os.inf.tu-dresden.de/~ch12 ##
Helmuth,
There exists a package that uses dde_linux to run Linux NIC drivers on L4, but unfortunately it's not in our public CVS up to now. ^^^^^^^^^ Does this mean that you will add it to the public CVS? Can you?
(see above) I think you have to hack a bit to get it running. Which NIC do you want to use (Linux driver file)? Maybe I could help you.
I was hoping that FLIPS would guide me in this choice but most probably the Intel e1000. Thanks Leon
participants (6)
-
Adam Lackorzynski -
Benno -
Christian Helmuth -
Frank Mehnert -
Leon -
R. Tyler Ballance