[Top][All Lists]

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

Re: Fwd: [Introspector-developers] status report

From: James Michael DuPont
Subject: Re: Fwd: [Introspector-developers] status report
Date: Sat, 18 Oct 2003 10:36:24 -0700 (PDT)

--- Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de> wrote:
> On Sat, Oct 18, 2003 at 03:13:59AM -0700, James Michael DuPont wrote:
> > > Yes, it is very consistent and abstract.  But, it is also
> incredible
> > > slow
> > > and resource heavy, and enforces a lot of policy on the user. 
> This
> > > slows
> > > down the fast path, and introduces some interesting DoS attacks.
> > 
> > OK, do you think that we can add in specific transformations and
> rules
> > into the compiler that will allow us to optimize some of this out?
> I
> > do.
> No, it's not possible.  The problems are not in the implementation or
> whatever local optimizations are possible, but in the interface
> design.

Well, I see that it is difficult to uproot code that uses a set of
abstractions to run on another set of abstractions. that is the type of
stuff that i am working on, a set of code refactoring tools. We will

> > What about a port registration utility that allows users to define
> > ports to be bypassed via simple function calls and to define the
> > semantics better? In a network environment you will want to have a
> > client certificate to be attached to the port to know who is
> attaching.
> Adding more features to the kernel will only make the matter worse.
> Any particular addition can fix the one or other security problem,
> but by
> adding even more costs.
i belive you. I need to look more into this, i am just starting.

> > So what do you plan on doing?
> We are working on a redesigned port to the L4 microkernel
> (www.l4ka.org).

Yes, I have gotten l4-hurd compiled and am working on the linker errors
> > > 
> > > And the Hurd is not difficult to compile either :)
> > 
> > No, it was quite easy once I cleaned out the mach code, I dont see
> why
> > the entry costs for compiling should be so high?
> The entry cost for compiling is installing the Hurd, or installing a
> vanilla
> cross compiler.  You did some odd, I have no clear idea what, but it
> was
> only complicated because you ignored the standard paths.

I just made a new set of mach headers, without all this BS in it.

> > Cannot mach/hurd run
> > in user mode and be implemented as a set of linux constructs?
> For Mach, probably.  Can BSD be compiled and run on Linux?  Can
> Windows be
> compiled and run on OS/2?  Maybe.  It's not part of our project.
> And it has nothing to do with the Hurd.  The Hurd needs the Mach
> headers,
> point.  If you build a user space Mach for Linux, you still have to
> install
> a cross compiler and the Mach header files.
> The Hurd can _not_ run directly on Linux, and with high certainity
> never will.
> > at least
> > for the libstore and libstream/channel it should be possible to
> test it
> > under linux.
> I think you have still no clear idea what you are talking about. 
> Only parts
> of that just need simple device access, others need the ports
> functionality.
> The same can be said of every software.  Parts of ext2fs translator
> can run
> on Linux, but the whole can not.  It's just a broken idea from the
> start.

I dont see why the libstream/libchannel could  not be tested on a
testing framwork under linux.

It is just isolation that is needed.


James Michael DuPont

Do you Yahoo!?
The New Yahoo! Shopping - with improved product search

reply via email to

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