[Prev][Next][Index][Thread]

Overriding stuff from OSKit libs, some random remarks, and patches

Hi OSKit-users,

I have been adapting the OSKit (snapshot 990722) to the Fiasco and L4
microkernels' user environment.  I have been selectively overriding
stuff with L4-specific implementations, and to make a long story
short, I managed to get several of the example programs to run
virtually unmodified on user level on top of Fiasco; in particular,
`linux_fs_com', `multiboot', `pingreply', and `socket_com'.

I'm pretty impressed with you OSKit guys' work -- it was quite easy to
find which bits had to be replaced (osenv_{irq,intr,mem}, and some of
the startup and exit code), and actually replacing those bits wasn't
difficult either (thanks to the very clean and logical L4-microkernel
interface the system's easy-to-use low-level resource servers ;-).
Took about 20 hours all-in-all.

One area where I did have trouble was convincing the linker that it
should actually use stuff from my library and not from the OSKit's
libraries.  For example, the linker liked to use osenv_irq_enable()
from liboskit_dev and not from my lib even though my lib was first on
the command line because this symbol was first used from within
liboskit_dev.

I eventually developed a kludgy solution to this problem: Wrapper
header files to the real ones reference special symbols defined in my
library to suck them in first; as an example, here is my
<oskit/dev/osenv_irq.h>, which comes before the real
<oskit/dev/osenv_irq.h> in the include path:

    #ifndef OSKIT10_SUPPORT_OSENV_IRQ_H
    #define OSKIT10_SUPPORT_OSENV_IRQ_H

    /* suck in our version of osenv_irq */
    asm(".globl l4_oskit_support_osenv_irq");

    #include_next <oskit/dev/osenv_irq.h>

    #endif

There ought to be a better way.  How do you solve this problem?

A few other minor problems I stumbled over:  

When building the OSKit by doing a "make" in the top-level directory,
the make process sometimes aborts with a terse message similar to
"make: Aborted".  Just restarting "make" finishes the build process.
Any idea what's causing this?

I found that examples/x86/linux_fs_com.c only works if I add a call to
start_clock() near the beginning.  Otherwise some call to
gettimeofday() fails.  I haven't tried this program without my L4
adaption, but I guess it has the same problem when running standalone.

Finally, I've appended a few simple patches: The first one extends
bootp/bootp.c so that the BOOTP request contains an RFC1048 cookie.
Some BOOTP servers otherwise don't include the RFC1048 vendor
extensions (default router, netmask, ...) in the BOOTP reply.  The
other patches add prototypes to several header files so that GCC's
-Wmissing-prototypes option (which we use extensively) is happy with
them.

Cheers,
Michael
-- 
hohmuth@innocent.com, hohmuth@sax.de
http://www.sax.de/~hohmuth/

Binary data

Follow-Ups: