l4-hurd
[Top][All Lists]
Advanced

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

Moving forward (was L4Hurd at Sourceforge)


From: Ian Duggan
Subject: Moving forward (was L4Hurd at Sourceforge)
Date: Tue, 23 Oct 2001 11:24:23 -0700

> Why? I suppose that we'll use dresden's modules unmodified and let the
> maintainers support Fiasco directly. We'll just have to submit patches
> (if we happen to find some) and I'm sure that Michael and others would
> glady apply them if they make sense for them. The same holds for Hazelnut
> (or any successors).

This makes sense too. I was thinking it'd be easier if we could grab
everything that we needed from a single CVS. I'm not expecing a lot of
changes either. The only one I can think of offhand is a patch to allow
fiasco to boot with more that 128MB of memory installed.

> Here again, we _could_ do that, but it may be IMHO better to branch
> off a l4-hurd branch at savannah directly.

I'm between jobs right now, so I have time to work on this. This would
depend on how easy it would be to convince the Hurd people to allow
write access to their CVS for this project. I'm more interested in
generating some progress. It'll be easier to get access once we have
something to show. At the moment, it's just a lot of bright ideas. We
need some code.

> To summarize: I don't see any reason to import the Hurd sources right
> now into l4hurd CVS, because I don't expect that we will modify them
> any time soon.

Convenience, write access, and a record of our changes are again my
thinking here. We also can't code against a moving target. It seems to
me that it would be easier to have our own version to work with so that
we could merge their progress into our stuff as things progress. That
way we are feeding patches in both directions, and we don't have to feed
the real Hurd anything until we have it at a point where it is good
enough to do so.

> I'd suggest that we restrict ourselves to the APIs (C-Bindings)
> that are common in at least fiasco and hazelnut for now. Best way
> to ensure this would be to compile (and test!) with both kernels
> simultaneously.

I agree that we should work with both kernels. Everyone seems to be
saying hazelnut to start, so I think it's decided. Hazelnut it is.

> Do we have to use oskit at all? If so, I'd prefer that its use be
> purely optional, e.g. for single (non-essential) user-level tasks

I guess not. It's a part of the fiasco CVS right now. I don't know what
the interdependencies are. Since we are using Hazelnut, I guess it isn't
important at the moment.

-- Ian

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Ian Duggan                    address@hidden
                              http://www.ianduggan.net



reply via email to

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