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 _______________________________________________ Help-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/help-hurd
