Re: Improving Hurd

[Jan Atle Ramsli]

Marcus Brinkmann wrote:
> 
> On Sun, Apr 21, 2002 at 04:31:15PM +0200, Jan Atle Ramsli wrote:
> > I do not want to hijack the Hurd for my own dark purposes.
> > I am 42 years old, I am not looking impress the girls.
> 
> Hey, but ... it works! :)
> 
> > I try to find a way to contribute.
> 
> The best way to get into the Hurd for an experienced programmer is probably
> to read the interface definition files in the Hurd source code:
> hurd/*.defs
> 
> Those files define what I think you mean with strategy.  They are the Hurd
> server interfaces used by the C library to implement the POSIX interface,
> and that is used among the Hurd servers to implement the Hurd (d'oh).
> 
> A good start is hurd/auth.defs, which defines the Hurd authentication model.
> Then you can go on with whatever you are interested in.  file interface in
> fs.defs, I/O interface in io.defs etc.  Lot's of interesting stuff, and the
> implementation is in the various Hurd servers (we recommend use of TAGS so
> you can browse quickly around the source code).
> 
> The documentation is incomplete, but it's better than in some other big
> projects, so you should have a reasonable head start.  Of course you should
> look around for the Mach books (kernel principles, kernel interface, server
> writer) which help with the details of the RPC interface.
> 
> You need the sources of the Hurd and the C library at least, but gnumach is
> also useful.  Which brings me to the interrupt stuff.  Hardware access is
> close to how it is in other kernels, like Linux or BSD, at least in gnumach.
> In oskit-mach it is mostly encapsulated by OSKit.  In anyway, if that's what
> you are interested in you should look into OSKit.  We need your help!  A lot
> of drivers are missing in OSKit, and people experienced in driver
> development can help integrating Linux or BSD drivers into the OSKit, so we
> can make use of them.
As far as I'm concerned, your mail above is a significant piece of
documentation - I have a good mind to rip it off and paste into a
'Programmers guide' (with your permission, of course :-)

This is probably one Hurdle (sorry) overcome: Who do I talk to, who does
this & that, & what 2 do to be most productive, etc - meta-questions.
I have never been part of a multi-programmer-free-software project.
Of course, I have taken a program made by someone else, hacked it beyond
recognition and sent it to oblivion, but that is sequential. This is
parallel. I can promise you it is confusing.
Non of us are administrators, there is nobody 'in charge' - I guess
somebody who could be in charge hestitates to _take_ charge for fear of
flames & stuff.

All my questions (asked and non-asked) are now answered.

I have gotten the information I was looking for, and I've got something
more - an extremely important 'feel' for how this is done.

There is no 'System Specification' - if you want one, make one.
(Then, what if it turns out that the design is wrong according to
specification? Fix it!)

Also, and this I think is as important: There is no 'support
infrastructure' - there's a bunch of guys, _just_like_you_, somewhere,
who may, may not, or may partly know what you ask, what you thought you
asked ... and the answer may even be wrong. 

There is no money-back guarantee.
There is no money, final.

I am staring to get it.
That is, I am starting to see how I might find a way to try to fit in.

That was my meta-goal, of sorts.

What started out as a half-frustrated, half joke comment from me about
the time it took to do this, produced one of the most significant pieces
of meta-documentation I have seen concerning the project.

Filtering out the garbage, this whole thread could become documentation.

Atle