headers
Farid Hajji | 1 Jul 01:28

[drops <at> os.inf.tu-dresden.de: ANNOUNCE: L4Env version 0.1]

Hi,

just in case someone missed the announcement.

Caveat: L4Env is GPLv2, not LGPL nor BSD-style.
For the GNU Hurd/L4, that's okay. For *BSD/L4,
it's not.

Regards,

-FH.

------- Start of forwarded message -------
X-From_: l4-hackers-bounces <at> os.inf.tu-dresden.de  Mon Jun 30 23:56:58 2003
Date: Mon, 30 Jun 2003 23:50:36 +0200 (DFT)
From: DROPS-Team <drops <at> os.inf.tu-dresden.de>
X-Sender: jork <at> os.inf.tu-dresden.de
To: l4-hackers <at> os.inf.tu-dresden.de
X-Mailman-Approved-At: Mon, 30 Jun 2003 23:54:26 +0200
Subject: ANNOUNCE: L4Env version 0.1
Sender: l4-hackers-bounces <at> os.inf.tu-dresden.de
X-Spam-Status: No
X-Scanned-By: MIMEDefang 2.15 (www dot roaringpenguin dot com slash mimedefang)

The DROPS team is happy to announce the first release of the
L4Env programming environment.

L4Env is a programming environment for application development on top of
the L4 microkernel family. It is developed as a part of the Dresden
Real-Time Operating System (DROPS).
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andrey V. Kateshov | 1 Jul 12:12

what about L4 HURD, is it alive?

Hello Ian.
Would you mind to explain what is current state of the project. I
would like to participate, but still it seems that yet there is nothing to
participate in. If it is so, would mind to share the main goals of the
project.
Thank you.

Andrey V. Kateshov aka hellmean
Permalink | Reply | 0 comments |
headers
Marcus Brinkmann | 3 Jul 00:05
Picon
Favicon

Re: local vs global object IDs

On Tue, Jun 03, 2003 at 03:53:11PM +0200, Ludovic Courtès wrote:
> Note that global IDs may cause troubles if they are used within a
> persistent task as we discussed it some time ago [1]

Other requirements now seem to force us to use another level of indirection
anyway, so it might be that after all resistance you will get your local IDs
anyway.  The reason is that if a server dies, we want to release the
reference to its task ID quickly.  This would not be possible if the server
thread ID is stored and referenced directly by a thread, but only if there
is an intermediate capability name that points to the server and object id.

In fact, such "dead objects" are exactly what would then need to be detected
and caught transparently in the persistent case.  However, they also need to
be detected (with an error message) in the non-persistent case.

Thanks,
Marcus

--

-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    marcus <at> gnu.org
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
Marcus.Brinkmann <at> ruhr-uni-bochum.de
http://www.marcus-brinkmann.de/
Permalink | Reply | 0 comments |
headers
Ludovic Courtès | 3 Jul 09:45
Picon
Picon
Favicon

IDL4 and flexible bindings

Hi,

Those of you who will attend the Libre Software Meeting next week will
have the opportunity to hear about a component-based OS framework called
THINK [1].  One of its potential advantages over the multi-server
approach is that components are not necessarily servers: bindings
between components are very flexible and can be implemented by a
function call, a system call or an RPC.  The type of a binding between
two components can even be changed dynamically IIRC.  This gives the
ability to interpose on bindings and dynamically change the
implementation of a given service.

Looking at the `weaver' example that comes with IDL4 1.0.0, it seems
that IDL4 could be used pretty much like an open compiler.  For example,
it could be used to develop the same kind of flexible bindings as the
one used in THINK. :)  An interface for controlling bindings could be
created for each binding and it would, for instance, allow to load a
monitor (e.g. in the form of a dynamic library) which would be
automatically notified of any call to a function defined in the
interface.  This would make interposition and dynamic reconfiguration
easy to implement, and with relatively low overhead compared to stacked
servers.

Has there been any thoughts on this?

Thanks,
Ludovic.

[1] http://think.objectweb.org/
(Continue reading)

Permalink | Reply | 1 comment |
headers
Espen Skoglund | 3 Jul 12:19
Picon
Favicon

Re: IDL4 and flexible bindings

[Ludovic Courtès]
> Hi,
> Those of you who will attend the Libre Software Meeting next week
> will have the opportunity to hear about a component-based OS
> framework called THINK [1].  One of its potential advantages over
> the multi-server approach is that components are not necessarily
> servers: bindings between components are very flexible and can be
> implemented by a function call, a system call or an RPC.  The type
> of a binding between two components can even be changed dynamically
> IIRC.  This gives the ability to interpose on bindings and
> dynamically change the implementation of a given service.

> Looking at the `weaver' example that comes with IDL4 1.0.0, it seems
> that IDL4 could be used pretty much like an open compiler.  For
> example, it could be used to develop the same kind of flexible
> bindings as the one used in THINK. :) An interface for controlling
> bindings could be created for each binding and it would, for
> instance, allow to load a monitor (e.g. in the form of a dynamic
> library) which would be automatically notified of any call to a
> function defined in the interface.  This would make interposition
> and dynamic reconfiguration easy to implement, and with relatively
> low overhead compared to stacked servers.

> Has there been any thoughts on this?

The L4Ka team has, as you might know, been involved in componentized
systems.  A multi-server system where every single component resides
within each own protection domain is only the extreme case of such a
system.  We are very well aware of the possibility of having multiple
components within a single protection domain---either as separate
(Continue reading)

Permalink | Reply | 0 comments |
headers
Etienne Robillard | 12 Jul 21:47
Picon
Favicon

Accessing the L4 API with XS for fast stub-code generation (IDL4::CORBA)

Sup guys,
long time no see heh ? ;P

I was rovering over the perlxs man pages and I
found(?)
that PERL/XS might be usable with the L4 API for easy
method construction in XS/XSUB langage.

I need to know what you guys think of this. My problem
was that I needed some way to translate, let's say,
GNU HURD *.defs files in an optimized IDL4 format.
That manner, the {IDL::CORBA} module would contain all
methods needed: 

i.e $interface->some_func($foo, ...) 
$my_hurd = use IDL::CORBA::packet();

Anyways, Im trying all of this with Pistachio-0.1 . So
I quite don't know how you guys foresees IDL4
implementation in user-level. Further, I have no idea
if IDL stub code generation is plausible and or
realisable with XS. The advantages of this approach
are that it would offer a clean modular interface to
the user, as well of being extensible for many
platforms.

See ya 'round,

Etienne
(Continue reading)

Permalink | Reply | 0 comments |

Gmane