Farid Hajji <farid.hajji(a)ob.kamp.net> writes:
> BTW, is anyone in the L4 community currently implementing a pager task
> that would resemble Mach-VM or, even better, UVM? This is of general
> interest to all developers of L4-based OS-personalities, not just
> l4-hurd. Getting all the memory from sigma0 upon startup is not very sexy ;-).
The current VM management model of L4Env is roughly based on the ideas
described in
<ftp://ftp.cse.unsw.edu.au/pub/users/disy/papers/…
[View More]Aron_PJLED_01.ps.gz>.
See also the documentations for the L4 Region Mapper and Dataspace
Manager at the L4 Developer's Bibliography mentioned by Michael.
Lars
--
Dipl.-Inf. Lars Reuther Dresden University of Technology
Department of Computer Science Operating Systems Research Group
Phone: +49 (351) 463-38401 Fax: +49 (351) 463-38284
reuther(a)os.inf.tu-dresden.de http://os.inf.tu-dresden.de/~reuther/
[View Less]
Farid Hajji <farid.hajji(a)ob.kamp.net> writes:
> If the L4 people could provide us with a coherent view of the current
> (and upcoming) APIs and C-Bindings, that would be _great_! (hint, hint!)
The most coherent view on current APIs is available at
<URL:http://os.inf.tu-dresden.de/L4/bib.html>.
The L4 people in charge of the new L4 API (the Karlsruhe guys) have
decided to circulate the upcoming specification in a limited way first
to keep discussion short and efficient. …
[View More]They deemed this necessary
because they felt that the current draft is not self-explanatory
enough to be consumed by larger audiences without overloading its
developers with questions. Let's respect them regarding their
decision.
In the meantime (and in general), I suggest using library APIs that
will remain unmodified regardless of kernel version. Please have a
look at the upcoming L4 environment, which exists now and is
relatively well documented
<URL:http://os.inf.tu-dresden.de/L4/bib.html#l4env>. A release is
forthcoming as soon as the L4Env developers feel that their users
understand and are comfortable with their libraries. Try giving them
this impression! Or even better: Help them by writing a user's guide
for L4Env!
Michael
--
hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de
http://home.pages.de/~hohmuth/
[View Less]
Farid Hajji <farid.hajji(a)ob.kamp.net> writes in l4-hurd:
> [...] We'll probably also need glue code from OSKit to drop in the
> driver framework from Michael.
To clarify:
There are two L4 device-driver frameworks that are currently in use,
neither of which is ``Michael's framework.''
- One is a port of the OSKit to L4. It allows running OSKit
applications on top of L4 in user mode, including applications that
use OSKit's device drivers (which are mostly inherited from …
[View More]FreeBSD
and Linux).
It can be used to get applications up and running in short time on
x86 machines, but it is somewhat slow, produces huge binaries (most
of the time, the OSKit startup code links in *all* device drivers of
a class) and is not portable (the OSKit really only runs on x86).
Our distribution (available as part of our "l4" CVS module) includes
a number of example programs lifted straight from the set of
examples that came with the OSKit, including a "finger" client and a
filesystem example.
Here is the technical report I wrote on it:
<URL:http://os.inf.tu-dresden.de/~hohmuth/prj/oskit-l4.ps.gz>
- The other framework is a new development that is intended to fix the
OSKit problems I mentioned, developed mainly by Christian Helmuth
and Lars Reuther. This framework is intended to allow dropping the
source code of one Linux driver inside it, recompiling, and ending
up with a working L4 device driver.
This framework does not use the OSKit (AFAIK), but is based on our
new L4 environment, ``L4Env''.
A prototype for character-device drivers exists, but hasn't been
released yet.
Preliminary L4Env docs:
<URL:http://os.inf.tu-dresden.de/L4/bib.html#l4env>
A description of the device-driver framework (Christian's diploma
thesis, in German only):
<URL:http://os.inf.tu-dresden.de/~ch12/sub/diplom.ps>
Please bug the DROPS developers concerning releasing this stuff. :-)
Michael
--
hohmuth(a)innocent.com, hohmuth(a)sax.de
http://www.sax.de/~hohmuth/
[View Less]
Is this list still active? Are there other L4 lists that I should be on
as well?
-- Ian
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Ian Duggan ian(a)ianduggan.net
http://www.ianduggan.net
Farid Hajji <farid.hajji(a)ob.kamp.net> writes:
> > Currently, some of my colleagues are working on a framework that
> > allows you to (more or less) drop a Linux driver in a preconfigured
> > source tree and get a working driver that runs on the x86 L4 kernels
> > (L4/x86, Fiasco, L4KA). This framework, which will work with the
> > L4Env environment we're developing, is not quite ready yet, but it
> > might be worth the wait.
>
> Will the …
[View More]drivers run in userland on top of a vanilla L4 kernel?
Yes, they will.
> I'm wondering wether it would be possible to use (RPC?) the driver
> tasks directly from OS personalities like L4Linux, (L4BSD if someone
> wants to repeat the Lites experience on L4 ;-)) or the Hurd, possibly
> even simultaneously?
Yes. We have been working on stub drivers for L4Linux that use
external user-level drivers concurrently with (non-Linux) tasks. I'm
not sure right now which stub drivers we currently provide, but I
believe we already support console drivers and block-device drivers.
> > As an alternative, consider using the OSKit. We have developed a
> > compatibility library that allows you to run applications using the
> > OSKit (including the OSKit's device drivers) on top of L4. This work
> > is a bit unpolished and the drivers are slow, but it's quite easy to
>
> Good point. However, wouldn't it be necessary to link the driver
> libs to the Kernel? This is exactly what we want to avoid in the
> OSKit-Mach case sometime in the future (*Sigh*).
No, the drivers run completely on user level.
The OSKit has well-defined interfaces for low-level OS services such
as IRQ allocation and delivery. Reimplementing these interfaces for a
target system such as L4 (in particular parts of liboskit_dev and
liboskit_kern) makes it possible to port OSKit drivers to the target
system. OSKit drivers do not care whether they run on user level or
in kernel mode if all services they expect from liboskit_dev and
liboskit_kern are available.
Michael
--
hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de
http://home.pages.de/~hohmuth/
[View Less]
Farid Hajji <farid.hajji(a)ob.kamp.net> writes in l4-hurd:
[...]
> The second pressing point is to write/port a very small subset of device
> drivers to L4. We need a native L4 driver for ATAPI (or SCSI?) disks,
> so that the pager can use a real disk as backing store, and so that
> we can port a filesystem as well ;). Here too, no-one volunteered yet.
We in Dresden have extensive experience in porting Linux device
drivers to run directly on top of L4, so if you guys have …
[View More]questions,
don't hesitate to ask on the L4-hackers mailing list
<l4-hackers(a)os.inf.tu-dresden.de>.
Currently, some of my colleagues are working on a framework that
allows you to (more or less) drop a Linux driver in a preconfigured
source tree and get a working driver that runs on the x86 L4 kernels
(L4/x86, Fiasco, L4KA). This framework, which will work with the
L4Env environment we're developing, is not quite ready yet, but it
might be worth the wait.
As an alternative, consider using the OSKit. We have developed a
compatibility library that allows you to run applications using the
OSKit (including the OSKit's device drivers) on top of L4. This work
is a bit unpolished and the drivers are slow, but it's quite easy to
use. I even wrote a technical report on it:
<URL:http://os.inf.tu-dresden.de/~hohmuth/prj/oskit-l4.ps.gz>.
(You can find this and other reports in the L4 Developer's
bibliography at <URL:http://os.inf.tu-dresden.de/L4/bib.html>.)
Michael
--
hohmuth(a)innocent.com, hohmuth(a)sax.de
http://www.sax.de/~hohmuth/
[View Less]
Ian Duggan <ian(a)ianduggan.net> writes:
> I'm working to try to build the fiasco kernel for a pentium machine that
> I have. I'm working from a Debian PIII. Will I need to build a
> cross-compiler to produce code for the pentium machine?
No, you can use your Linux installation's native compiler.
> Working from the fiasco CVS, I can see how to invoke the --host options
> for "configure" of oskit and oskit10. Is there anything similar for
> doing this with the L4 …
[View More]module?
No, the compiler L4 uses is configured in l4/Makeconf. On Linux/x86
systems, it's just `gcc', on other systems its usually `i386-linux-gcc'.
Michael
--
hohmuth(a)innocent.com, hohmuth(a)sax.de
http://www.sax.de/~hohmuth/
[View Less]
Ian Duggan <ian(a)ianduggan.net> writes:
> Who is the maintainer for the current L4/Fiasco CVS? If I have patches
> to add to L4/Fiasco, to whom do I send them?
The best place to send them to is the Dresden's bug-tracking system at
<fiasco-bugs(a)os.inf.tu-dresden.de> (don't be fooled by the name --
use this address for L4- and Fiasco-specific changes alike).
If your patches are Fiasco-specific, you can also send them for review
directly to <fiasco-core(a)os.inf.tu-…
[View More]dresden.de>.
Regards,
Michael
--
hohmuth(a)innocent.com, hohmuth(a)sax.de
http://www.sax.de/~hohmuth/
[View Less]
Who is the maintainer for the current L4/Fiasco CVS? If I have patches
to add to L4/Fiasco, to whom do I send them?
-- Ian
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Ian Duggan ian(a)ianduggan.net
http://www.ianduggan.net