Re: Moving forward (was L4Hurd at Sourceforge)

[Niels Möller]

Ian Duggan <address@hidden> writes:

> > 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.

This makes some sense. When you start hacking on some or all of the
hurd code, add it, or relevant parts, to this repository.

But there's no need to copy any hurd code into the repository until
you start modifying it.

If you just want the target to stop moving, the easiest way to do that
is to put a tag into the hurd cvs, or stick to (some of) the debian
packages of the hurd. Then upgrade at well defined points in time.

> > 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.

Some device drivers will be needed quite soon (as outlined by Farid).
To me, it seems like the best way to do a device driver is as an L4
task, linked with the oskit libraries. If these L4 tasks can later be
upgraded to Hurd processes, the Hurd gets real user space device
drivers.

Whether or not the l4 kernel should use the OS kit is a different
question. My guess is no.

Another potential oskit user is the pager.

> >    vk-l4/gcc/         # specs and other modifications to gcc, if needed.
> 
> I'm unfamiliar with what this would be. What is a gcc spec file? Would
> we really need to modify gcc?

If you want to cross compile for odd setups, hacking the gcc specs
file (usually installed in lib/gcc-lib/<system>/<version>/specs) is
the way to put include paths, library paths, compiled code, libraries
and startup code together.

Ultimately, you should be able to build a suitable cross compiler with

  ./configure --target=i386-unknown-l4-hurd-gnu

or some such (the exact name was discussed earlier on this list so it
should be in the archives), but reusing the i386 compiler you have
around and hacking the specs is a way to avoid having to solve those
problems right away.

The only documentation of the spec file I know of are the comments in
gcc.c.

> Can we start with the sigma0 pager that comes with the various L4
> implementations? Maybe I'm misunderstanding what it is for.

I think Farid wrote a good description about what the pager should do.
If I understood it correctly, it should have similar features to mach
vm.

> > This way, we'd incrementally contribute code to a general purpose
> > infrastructure on top of L4 upon which we could not only base the
> > Hurd, but also other single servers (L4Linux, L4BSD<vaporware right 
> > now>,...)
> > 
> > What do you think?
> 
> It sounds like a nice idea if I am understanding it correctly. My only
> question is if this is maybe biting off more than we can chew initially.
> Would this distract from the initial goal of Hurd on L4?

I'm feeling the same way. The general L4 vk might be nice to have, but
it's not a primary goal, at least not now.

/Niels