l4-hurd
[Top][All Lists]
Advanced

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

Re: Part 2: System Structure


From: Marcus Brinkmann
Subject: Re: Part 2: System Structure
Date: Wed, 24 May 2006 16:15:24 +0200
User-agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (Sanjō) APEL/10.6 Emacs/21.4 (i486-pc-linux-gnu) MULE/5.0 (SAKAKI)

At Wed, 24 May 2006 15:24:33 +0200,
"Michal Suchanek" <address@hidden> wrote:
> > However, I believe that there are many good and interesting
> > applications where the instantiation operation influences heavily the
> > process composition operation.  For example, in Unix, shared libraries
> > are frequently replaced dynamically with LD_LIBRARY_PRELOAD or
> > LD_LIBRARY_PATH, not only in development, to achieve various goals.
> > Programs are run in specially prepared sessions, like ltrace, strace
> > (Unix), rpctrace (Hurd), fakeroot, to observe or control their
> > behaviour.  In the end, I want to make all types of virtualization and
> > debugging very easy.  The constructor sometimes makes them harder, by
> > putting a piece of infrastructure in the way of achieving these goals.
> 
> There see no reason why constructors would get in the way of such
> tools. You sould be able to trace the capabilities you give. In the
> cases the constructor gives a special capability you can still trace
> how the capabilities you gave are used.
> Admittedly you would have to create a new constructor for changing
> libraries or tracing the capability inserted into the constructor. If
> you have access to the capability yo can do so.

We already have a mechanism to provide such capabilities.  It is
called a "file" capability to the binary image.  This is all I need to
support all the features I want to support.  Everything beyond that is
"in the way".

> However, it is not yet completely clear what system we want. So it is
> not obvious which way it turns out.

It's not clear to me what "we" you are talking about.  There is the
Coyotos group, which has clear goals and definition, and there is the
GNU project which has clear goals and definitions.  And then there are
a couple of individuals who seem to have interest in both, but can not
offer any way to reconcile the conflicting interests.  I certainly
belonged to the latter until I made up my mind and drafted a proposal
that I think is compatible with the GNU goals and definitions.  It's
very much an open issue if the GNU project would adopt my proposal,
but there is little doubt in me that the GNU project will never accept
a proposal that supports DRM-like mechanisms.

Thanks,
Marcus





reply via email to

[Prev in Thread] Current Thread [Next in Thread]