Hurd/L4 active?

Hi,

Is this project still active developed?

Is the now the chosen microkernel for Hurd? If not then what kernel is and 
what are the
future development plans for Hurd.

I have also read about ngHurd, is this different code base then the current 
Hurd. If so then
why can't we all just contribute to the same code base and improve the 
existing Mach and
Hurd and rather then forking another Hurd project. This will delay Hurd even 
more??

Thanks
Shams

--

-- 

Re: Hurd/L4 active?

Hi,

On Fri, Apr 13, 2007 at 07:21:53PM +1200, Shams wrote:

> Is this project still active developed?

The original Hurd/L4 project isn't developed anymore for quite a while
now. There were some very fundamental problems with the original design.

> Is the now the chosen microkernel for Hurd? If not then what kernel is
> and what are the future development plans for Hurd.
> 
> I have also read about ngHurd, is this different code base then the
> current Hurd.

Since the death of the original Hurd/L4 port, this list has been used
for discussions about a totally new design, often referred to as ngHurd.
However, no code exists so far; and in fact it's still not clear what
microkernel will be used for it, or how the design will look exactly.

> If so then why can't we all just contribute to the same code base and
> improve the existing Mach and Hurd and rather then forking another
> Hurd project.

This is not really meant as a Fork; rather an experimental/research
subproject.

> This will delay Hurd even more??

Maybe, maybe not. Hard to tell. Some people are interested only in

Re: Hurd/L4 active?

Hi,

I read somewhere that instead of L4, Hurd could be using L4.Sec as the 
microkernel?
Is this still a possibility?

> rather an experimental/research subproject.

Why another subproject, why not just develop/experiment with the existing 
Hurd?

Btw who calls the shots at which microkernel Hurd is going to be using and 
the development
path for Hurd. Is it people like RMS, Thomas, Roland or who else or is no 
one incharge of this
project?

Thanks
Shams

--

-- 

<olafBuddenhagen <at> gmx.net> wrote in message 
news:20070413192036.GD5031 <at> sky.local...
> Hi,
>
> On Fri, Apr 13, 2007 at 07:21:53PM +1200, Shams wrote:
>
>> Is this project still active developed?
>

Re: Hurd/L4 active?

Scribit Shams dies 14/04/2007 hora 14:38:
> I read somewhere that instead of L4, Hurd could be using L4.Sec as the
> microkernel?

Both Coyotos and L4.sec could be used, it seems.

> > rather an experimental/research subproject.
> Why another subproject, why not just develop/experiment with the
> existing Hurd?

Because there are issues with the current Hurd that might not be
possible to solve while keeping Mach as the µ-kernel, at least (IIUC, in
terms of security and performance).

> Btw who calls the shots at which microkernel Hurd is going to be using
> and the development path for Hurd.

Those who write the code.

Quickly,
Pierre
--

-- 
nowhere.man <at> levallois.eu.org
OpenPGP 0xD9D50D8A

_______________________________________________
L4-hurd mailing list
L4-hurd <at> gnu.org
http://lists.gnu.org/mailman/listinfo/l4-hurd

Re: Hurd/L4 active?

Hi,

what can anyone do if he or she wants to help at the micro kernel thingie?

Spending time for the mach-kernel seems not very clever, if mach is going to be replaced.

Regards,
Martin

On Sat, 14 Apr 2007 13:43:20 +0200
Pierre THIERRY <nowhere.man <at> levallois.eu.org> wrote:

> Scribit Shams dies 14/04/2007 hora 14:38:
> > I read somewhere that instead of L4, Hurd could be using L4.Sec as the
> > microkernel?
> 
> Both Coyotos and L4.sec could be used, it seems.
> 
> > > rather an experimental/research subproject.
> > Why another subproject, why not just develop/experiment with the
> > existing Hurd?
> 
> Because there are issues with the current Hurd that might not be
> possible to solve while keeping Mach as the µ-kernel, at least (IIUC, in
> terms of security and performance).
> 
> > Btw who calls the shots at which microkernel Hurd is going to be using
> > and the development path for Hurd.
> 
> Those who write the code.

Re: Hurd/L4 active?

On Sat, Apr 14, 2007 at 02:14:10PM +0200, Martin Barth wrote:
> Hi,
> 
> what can anyone do if he or she wants to help at the micro kernel thingie?
> 
> Spending time for the mach-kernel seems not very clever, if mach is going to be replaced.

I strongly disagree. The idea of Hurd-NG was born *because* we tried with
Mach. Improving the current Hurd is at least a way to find new problems
and think of their solutions before trying something else. In addition,
many other systems, like monolithic kernel based systems, have inherent
flaws. That doesn't prevent them from being used and working in most
cases. Why would it be different for the Hurd ?

--

-- 
Richard Braun

_______________________________________________
L4-hurd mailing list
L4-hurd <at> gnu.org
http://lists.gnu.org/mailman/listinfo/l4-hurd

Re: Hurd/L4 active?

Hi,

On Sat, Apr 14, 2007 at 02:14:10PM +0200, Martin Barth wrote:

> what can anyone do if he or she wants to help at the micro kernel
> thingie?

You could help out with ngHurd, once Marcus and/or Neal take up the ball
again.

You could revive the existing (partial) Hurd/L4 port, moving it to one
of the new L4 variants; or start a new port of the existing codebase to
some modern microkernel.

You could join the x15mach development. This is a new variant of Mach
being implemented from scratch, but cleaner, more modern, and stripped
of any functionality not actually needed by the Hurd. The idea is to get
a kernel that is better maintainable than gnumach, and makes it easier
to make fundamental improvments. It's still far from coplete, however.

Or you could just help with improving the existing gnumach -- which is
still the only kernel actually used in a working Hurd implementation,
and thus the only one where improvements will immediately benefit the
Hurd...

> Spending time for the mach-kernel seems not very clever, if mach is
> going to be replaced.

Not at all. The Mach-based Hurd implementation won't go away any time
soon.

Re: Hurd/L4 active?

Hi,

On Sat, Apr 14, 2007 at 02:38:53PM +1200, Shams wrote:

> I read somewhere that instead of L4, Hurd could be using L4.Sec as the
> microkernel? Is this still a possibility?

Yes, L4.Sec is among the kernels that could be used for ngHurd.

It should also be possible to port the existing Hurd implementation to
L4.Sec or some similar variant (either picking up the Hurd/L4 work done
so far, or starting a new attempt), though currently nobody is planning
to do so AFAIK.

> > rather an experimental/research subproject.
> 
> Why another subproject, why not just develop/experiment with the
> existing Hurd?

The ideas proposed for ngHurd are not minor changes, but totally new
concepts. While personally I do believe that most of these things could
be implemented on top of the current Hurd/Mach code, experimenting with
totally new concepts can be easier when starting from scratch. Of
course, if some of the ideas turn out to work well, it's possible and
desirable to implement them in the mainline Hurd also -- or even make
ngHurd the mainline.

> Btw who calls the shots at which microkernel Hurd is going to be using
> and the development path for Hurd.

Coyotos kernel update

It's time for an update on Coyotos progress.

1. The current Coyotos specification (Version 0.5+, dated April 8) is
semi-frozen. Known open issues:

  1. Need to choose a scheduler interface (soon)
  2. Need to document the persistence layer (target: v1.1)
  3. Various minor issues and refinements that we know about where the
     correct resolution should be determined by experience with
     implementation. (target v0.6)

     Examples:

      A. Re-arrangement of bit positions in various objects.
      B. Introduction of cache hints in memory capabilities
      C. Whether cached short messages should be implemented, and if
         so, whether they should be handled by a separate system call
      D. Whether all received capability arguments must go to
         registers or not.

The 0.6 specification will incorporate these changes, and will accompany
the first Coldfire version.

The 0.7 specification will accompany the first IA-32 version.

2. As of this weekend we have started a marathon kernel implementation
effort. We expect this to last several weeks, and at the end we will
have an embedded kernel for Coldfire. This kernel will NOT be optimized
(in fact, it will probably be very slow), but it will be usable and it
will implement the correct kernel interface. The release will include

Re: Hurd/L4 active?

I would add to Olaf's list:

When Coyotos (or l4.sec) become available, you could work on a Mach
compatibility layer so that the existing Hurd code can run on the new
microkernel. This would be a great way to test the microkernel!

Unfortunately it is too early to start this quite yet.
--

-- 
Jonathan S. Shapiro, Ph.D.
Managing Director
The EROS Group, LLC