headers
Andreas Haeberlen | 6 Apr 2002 15:45
Picon
Favicon

IDL4 0.8.1 released

Hello L4 hackers,

IDL4 is now available for download from the L4Ka home page.

IDL4 is a stub-code generator for the L4 platform. It generates 
communication stubs from interface definitions written in a 
specification language such as CORBA IDL or DCE IDL. It also uses 
knowledge about the hardware platform and the microkernel to 
optimize the performance of the generated code.

Some features:

  o Supports CORBA IDL (recommended) and DCE IDL 
  o Backends available for Hazelnut and Pistachio 
  o Client stubs use CORBA C language mapping 
  o Type import from C/C++ code 
  o Modular design; easily extensible 

For more information please visit http://l4ka.org/projects/idl4/

  - Andreas

---
Andreas Haeberlen
System Architecture Group, University of Karlsruhe, Germany
haeberlen <at> ira.uka.de, phone: +49 (721) 608-4055
Permalink | Reply | 0 comments |
headers
Alan Grimes | 8 Apr 2002 20:08
Favicon

om

om/listcheck

I have a radical proposal, one that, untill now, has been thouroughly
rejected by the Open Source community: Lets make an OS that doesn't
suck! 

I have a design but working with current open source tools is a real
bitch. =( I hate Linux; read my headers. =P

--

-- 
Join a suicide cult.
Sign up for destructive brain uploading!
http://users.rcn.com/alangrimes/  <my website.
Permalink | Reply | 0 comments |
headers
Laurent Mallet | 16 Apr 2002 18:27
Favicon

L4, chmacos and hurd

 Hi,

Sorry for my poor english and thanks for your patience to read this message

I am Ellis and i am discovering the code of the mini os chmacos which is
based on L4 microkernel and i am finding this could be a good starting point to l4-hurd...
But to have a good beginning, it lacks some documentation too. So I am
trying to commentchacmos in french to make easyer to read it and later in english ...

This is the birth of l4-hurd but we need to organize the task with :
1/ A good documentation
2/ A website : people which make this project visible.
3/ A roadmap (detailled)
4/ Groups which can organize the differents tasks.

I am observing the openbeos project and find this project very alive and
interesting. I thinkthis could be a good example for this project.

---------------------------
Laurent mallet aka ellis
mallet <at> linagora.com
---------------------------
Permalink | Reply | 1 comment |
headers
Farid Hajji | 19 Apr 2002 09:55

Re: Roadmap?

> Note that I didn't say anything on L4, as it is hard for me to assess
> how much work is being done there, because the L4 work probably can't
> just be started, but must be planned carefully. I can see that some
> planning has been done, but one of the people working on it would have
> to comment on the status.

Status of the Hurd/L4 port:

1. Ian set up a project at savannah:
     http://savannah.gnu.org/projects/l4hurd/
   Currently only skeleton project, but new code will eventually
   be submitted there.

2. We'll code against the new L4 Version 4 specification.
   That spec has not yet been released, but a preliminary experimental
   spec. has been approved by the L4 community:
     http://l4ka.org/projects/version4/
     http://l4ka.org/documentation/files/l4-x2.pdf
   Espen is still coding the Pistachio kernel, which will implement
   the Version 4 API.

   In the mean time, most of us use Hazelnut
     http://l4ka.org/projects/hazelnut/
   for tests and to get acquainted to L4 principles and (old) APIs.

3. We'll most likely use some kind of RPC generator as a replacement
   to MIG. One of the stub generators is IDL4:
     http://www.uni-karlsruhe.de/~uhns/idl4/

   Anybody interested in playing with IDL4 and Hazelnut is strongly
(Continue reading)

Permalink | Reply | 0 comments |
headers
Farid Hajji | 19 Apr 2002 10:05

Re: L4, chmacos and hurd

Hi Ellis,

> I am Ellis and i am discovering the code of the mini os chmacos which is
> based on L4 microkernel and i am finding this could be a good starting point to l4-hurd...
> But to have a good beginning, it lacks some documentation too. So I am
> trying to commentchacmos in french to make easyer to read it and later in english ...
great! Thank you for your help. The more, the better! ;-)

> This is the birth of l4-hurd but we need to organize the task with :
> 1/ A good documentation
> 2/ A website : people which make this project visible.
> 3/ A roadmap (detailled)
> 4/ Groups which can organize the differents tasks.
We already have a project at savannah:
  http://savannah.gnu.org/projects/l4hurd/
but we need volunteers to code (and document!).

If you're willing to help, a good starting point would be to gather as
much information about L4 (both old and new APIs) and write a good intro
to prospective Mach and Hurd hackers. We lack a consistent introduction
to L4 for Hurd people right now.

Just an idea...

> Laurent mallet aka ellis
> mallet <at> linagora.com

Regards,

-Farid.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dr. William Bland | 19 Apr 2002 12:19

Re: Roadmap?

On Fri, 19 Apr 2002, Farid Hajji wrote:

> As Wolfgang said, nothing will happen unless we get more volunteers
> to help. There are some time constraints (like, we're waiting for
> Pistachio etc...), but a lot of things can already be done right
> now by people with some spare time ;-).

I'd like to offer to help, but I'm not really sure how I can.  Perhaps
it's still too early for people like me to do anything?  I program in
C, Java and a little C++ but probably at more of an applications level
than what is needed.  The closest thing I've done to "kernel
programming" is adding support to gphoto2 for my usb camera (i.e. a
usermode driver - not very close to kernel programming at all ;-).
Still, if there's anything anyone thinks I might be able to do, keeping in
mind that I have a day job, please let me know.

Best wishes,
		Bill.

--

-- 
Dr. William Bland.  email: wjb at netpd dot com.
Microsoft makes simple tasks easy and complex tasks impossible.
Sometimes it makes the simple tasks impossible too.
Permalink | Reply | 0 comments |
headers
Farid Hajji | 19 Apr 2002 15:14

Re: Roadmap?

Hi Bill,

[Cc: trimmed to l4-hurd]

> I'd like to offer to help, but I'm not really sure how I can.  Perhaps
> it's still too early for people like me to do anything?  I program in
> C, Java and a little C++ but probably at more of an applications level
> than what is needed.  The closest thing I've done to "kernel
> programming" is adding support to gphoto2 for my usb camera (i.e. a
> usermode driver - not very close to kernel programming at all ;-).

you don't need to be a kernel hacker to help :-)

> Still, if there's anything anyone thinks I might be able to do, keeping in
> mind that I have a day job, please let me know.

It depends on your personal preferences and tastes. After all, this
is a pure volunteer project; we're working on parts that we either
like very much or that we need for work. Personally, I'm currently
digging in UVM because I need this for a NetBSD/L4 port as well as
a distributed VM project  <at> work. You'll certainly have similar
considerations too.

IMHO, the best way to get started with L4 hacking, is to actually
_write_ some root-tasks and exercise the L4 APIs. In your spare
time, consider writing a few root-tasks on top of, say, Hazelnut.
One app could consist of a root-task that spawns other tasks and
have them IPC directly. After this, try RPC with IDL4 etc... This
way, you could quickly learn a whole lot about L4 in general and
could then start doing "real work" ;).
(Continue reading)

Permalink | Reply | 0 comments |
headers
Marcus Brinkmann | 19 Apr 2002 16:35
Picon
Favicon

Re: Roadmap?

On Fri, Apr 19, 2002 at 09:55:46AM +0200, Farid Hajji wrote:
> 6. Driver Support: Two models are being investigated:
>       6.1: OSKit drivers
>       6.2: L4Env (http://os.inf.tu-dresden.de/L4/bib.html#l4env)
>    We're waiting for a release of L4Env.

Uh, that can take some time :)

>    It's not yet clear wether we should stick to Mach's device API
>    or if the oskit-mach people are considering a totally new approach.
>    Basically, the drivers must be implemented in user-space (L4 API
>    sends INTs to driver threads through IPC, much like in Mach).

The Mach device interface is open, read, write, close, I don't see how you
can have anything else.  The details are almost insignificant, it's trivial
to go from one interface to another.  With one exception, and that is the
terminal interface.  Luckily, the braindead Mach terminal interface is
completely encapsulated in term/device.c (or something like that), and you
just need to rewrite this file if you use a saner semantics.

I suggest to work on putting OSKit drivers into user space now, and try to
get it working with Mach and/or L4.  Waiting for L4Env is probably not so
good an idea before we know more about it (it might after all never really
mature, while OSKit has a lot of drivers already and works quite well).

Thanks,
Marcus

--

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd <at> debian.org
(Continue reading)

Permalink | Reply | 0 comments |
headers
Farid Hajji | 19 Apr 2002 19:28

Re: Roadmap?

> >    It's not yet clear wether we should stick to Mach's device API
> >    or if the oskit-mach people are considering a totally new approach.
> >    Basically, the drivers must be implemented in user-space (L4 API
> >    sends INTs to driver threads through IPC, much like in Mach).
> 
> The Mach device interface is open, read, write, close, I don't see how you
> can have anything else.  The details are almost insignificant, it's trivial
> to go from one interface to another.  With one exception, and that is the
> terminal interface.  Luckily, the braindead Mach terminal interface is
> completely encapsulated in term/device.c (or something like that), and you
> just need to rewrite this file if you use a saner semantics.

Right.

I didn't mean the Mach <-> user-space dev_*() interface you mentioned
above (that is easy), but rather the (future) interface between L4
(and Mach?) and the user-space drivers. Things like passing INTs to
the drivers or clearing them, locking w. cli/sti etc...

> I suggest to work on putting OSKit drivers into user space now, and try to
> get it working with Mach and/or L4.  Waiting for L4Env is probably not so
> good an idea before we know more about it (it might after all never really
> mature, while OSKit has a lot of drivers already and works quite well).

That is a very good idea indeed. We could start with a few essential
drivers like: serial, keyboard, vga, and probably atapi/disk. Any takers?

-Farid.

--

--
(Continue reading)

Permalink | Reply | 0 comments |
headers
Farid Hajji | 21 Apr 2002 19:31

Design Decisions and Hurd/L4 work (was: Re: Improving Hurd)

Hi Atle,

it may be futile, but let's try to put this thread back on
track by talking about what can be done _now_ and postpone
the philosophical issues for later. Sorry for interfering
in that very amusing discussion and for forking off another
thread. ;-)

[Cc: l4-hurd, since it covers Hurd/L4-relevant stuff. Please Un-CC
when L4 is no longer concerned. Thanx]

> > > I think you may find that this will improve with the change from
> > > Mach to L4.  But imagine if the first year had been used to analyze
> > > and specify it.
> > 
> > Why? The Hurd is not Mach, or L4, it is just a bunch of translators and is
> > quite independent of Mach. Yes, we do use drivers and such from it, but I
> > don't see why it would change anything if we change to L4.  Sure, we might
> > get some speed, but until I see some numbers that the Hurd runs faster
> > on L4 I won't believe it. :)

The purpose of the Hurd/L4 port is not primarily speed, but to get
a better design of the Hurd. If speed is your concern, there are lots
of possible improvements in Hurd/Mach right now. Just think of
unnecessary copying, the fork() issue, etc... All this _could_ be
fixed by any knowlegeable Hurd hacker right now. But it is still
too early to optimize for speed, since we have more pressing issues
to solve.

The Hurd/L4 port forces us to rethink many design decisions that
(Continue reading)

Permalink | Reply | 0 comments |

Gmane