Re: Moving forward (was L4Hurd at Sourceforge)

[Farid Hajji]

> 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.
I don't know if others on this list experienced difficulties with
Dresden's CVS server. They seem to have a flaky server sometimes,
but not recently.

> > 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.
The Hurd is currently a creeping, rather than a moving target ;-).
Seriously though: Niels rightly suggested that we only add things
to CVS that we are currently also working on. I agree with Niels
here, because I don't expect us to compile glibc/l4 or hurd/l4
in its entirety in the next couple of weeks. If we followed Roland's
suggestion by porting 'boot' and hurd/utils/shd.c, that would
certainly belong into our l4hurd/ directory. The rest of the
Hurd/Glibc code is readily available through savannah, so I don't
see the need to import that here. We really should incrementally
port the Hurd and move the changed code to l4hurd/ when we're ready
to work on it. At least, this is what I'd suggest.

> > 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.
Okay. No objections here ;)

> > 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.
When you really realize how slim L4 is, you'll quickly see the need for
OSKit components. My point is we should restrict ourselves to use
OSKit only in user-level tasks like, say, pager, driver-tasks etc,
but certainly not in L4 itself.

-Farid.

-- 
Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555
Broicherdorfstr. 83, D-41564 Kaarst, Germany  | address@hidden
- - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - -
One OS To Rule Them All And In The Darkness Bind Them... --Bill Gates.