[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 03:13:59 -0700 (PDT)

--- Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de> wrote:
> On Fri, Oct 17, 2003 at 01:52:14PM -0700, James Michael DuPont wrote:
> > > I was a bit surprised at your assertions about Mach and Hurd,
> too. 
> > 
> > I think that mach has a very interesting and clean api for IPC. The
> > usage of ports everywhere makes it clean. Much more interesting
> than
> > the linux kernel.
> 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

> There are also some crucial features missing.  For example, you can
> not
> identify the owner of a port, or where a message came from.  

What about having 

> allows a
> user to hide ports in other tasks as reply ports to blocking
> messages,
> causing cyclic dependencies and thus resource leaks (similar to fd
> passing
> and pipes, where in Unix a similar problem exists [might be fixed in
> some
> kernels]).

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.
> The point being here that Mach's IPC system is nice if you are
> looking at
> the abstraction.  But if you take performance, stability and
> accountability
> into your consideration, you will quickly realize (with the help of
> the last
> decade of OS research) that the cleanliness comes at a great, and for
> a
> microkernel design unbearable, cost.  Plus the features that are
> really
> expensive are rarely or never used, but you pay for them all the
> time.

So what do you plan on doing?

> 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? Cannot mach/hurd run
in user mode and be implemented as a set of linux constructs? at least
for the libstore and libstream/channel it should be possible to test it
under linux.


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]