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).

Prior to L4Env, most L4 applications had their very own idea about the
environment (libraries, interfaces and so on) in which they were executed.
Almost every programmer had his own set of libraries he used to build his
applications, which resulted in huge problems if someone tried to combine
components developed by different authors. Frequent problems were
conflicting implementations of common functions (like printf) or conflicts
caused by the lack of a central management of resources like threads or
virtual memory.

The intention of L4Env is to define a set of functions which describe a
minimal environment. This minimal environment is available for every L4
application. Hence, all applications and especially all libraries can use
these functions. Libraries which are intended to be used by many different
applications should only use these functions to avoid dependencies to
other libraries.

L4Env also decreases the dependencies to a certain L4 API or hardware
architecture, making applications more portable.

L4Env is available under the GPL version 2 licence. For different
licensing schemes please contact drops <at> os.inf.tu-dresden.de.

Source distributions, documentation, and other online resources can be
found on the L4Env website:

   http://os.inf.tu-dresden.de/l4env/

The DROPS Team
Operating Systems Group
University of Technology Dresden, Germany

_______________________________________________
l4-hackers mailing list
l4-hackers <at> os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
------- End of forwarded message -------

--

-- 
Farid Hajji -- Unix Systems and Network Management.
http://www.farid-hajji.net/address.html
Quoth the Raven, "Nevermore." --Edgar Allan Poe.
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/
Permalink | Reply | 1 comment |
headers
Espen Skoglund | 3 Jul 12:19
Picon

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
threads (e.g., for synchronization reasons), or as function calls.
Indeed, the various degrees of connectivity between components is
something that we envision as a parameter set during system
configuration/build time.  An IDL compiler is then crucial if the
component developers are to have a component-connectivity-agnostic
view on the development process.  However, in order to support the
various degrees of connectivity we are currently occupied with
investigating the most extreme case of component connectivity, i.e.,
multi-server systems.

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

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

=====
iD

______________________________________________________________________ 
Post your free ad now! http://personals.yahoo.ca
Permalink | Reply | 0 comments |

Gmane