[Top][All Lists]

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

Re: gnumach release

From: Marcus Brinkmann
Subject: Re: gnumach release
Date: Wed, 22 Aug 2001 00:02:29 +0200
User-agent: Mutt/1.3.20i

On Tue, Aug 21, 2001 at 05:09:30PM -0400, Roland McGrath wrote:
> > I think that we should try to fix the support for a large amount of memory. 
> > Somebody posted a work around today to debian-hurd, and as it is in the
> > Linux code, maybe it is not too difficult to find the real fix by looking at
> > some newer version of this Linux code.
> Ok.  That workaround doesn't make sense to me, and I don't know any details
> about exactly what the problem is when it comes up.  The code in question
> is in Shantanu's or Okuji's support code for the Linux drivers, not in
> copied Linux code per se.  So there is no obvious parallel to compare to.

Ui, I missed that.  Mmmh.  Maybe not worry about it for 1.3, it might take
some time to get it worked out between those people who actually have so
much memory and those who know what to do about the code (if there is no

> > I have made a huge progress with mach.texi, which is now 157kb large and
> Excellent.  I didn't even know you had been doing this (or anyway I
> forgot).  But I don't think we should worry about this for the release.

Works for me.  It's better not to get a schedule for this, so it can mature
at its own pace.

> We might as well just release the documentation separately whenever it is
> ready, under the FDL if possible.  

Yes, the reason it is GPL right now is that I simply copied the beginning
from the Hurd manual (c&p as quickstart).
> If you also had compilation instructions for gnumach in there, it would
> make sense to break those out into a separate install document that goes
> into the gnumach tree, and we could put that into the 1.3 release if you
> have something.

Ok, I will give it some thought how to split it up best.  You already gave
the correct outline how it should happen, I think.
> Ok, I've just downloaded your file and looked at it.  Very GNUish.

Is that a good or a bad thing? :)  This is my first info manual, and I
looked at the Hurd and glibc manual for how to do the formatting of
functions and their description.

> You should post something to the lists about that soon and get some
> volunteer help in finishing it up;

It's in the works (one volunteer I already gathered seems to have dropped
the ball).  However, it doesn't make sense for me to ask if I can't put the
offers into action, so it will have to wait a few days so I know I can
handle the rush of volunteers ;)

> The obvious addition it could use is documentation of the boot script
> syntax, which has never been really specified anywhere before.

The boot procedure is of particular importance indeed.

One thing about the manuals:  It would be good to be able to take advantage
of the OSF documentation ( etc).  Alas, we have no
license for them (mind you, no license at all).  Moritz already mailed RMS
if there is any contact to OSF/CMU to probably get a good license so we can
copy from it, nothing has happened yet.  If Thomas or someone else can be
of help here, let us know.

Beside the interface changes (the device interface is not documented in
the man pages at all, some interfaces were obsoleted and some are new),
it would also be good to be allowed to copy freely from the server writer
and kernel principle document.  I think one could pretty easily hammer a mig
manual out of them, among other stuff.

I don't plan at all to devote much of my time to documentation authoring,
but the possibility to C&P from those manuals leads fast to quite usable
documents, so we should not miss the chance.


`Rhubarb is no Egyptian god.' Debian address@hidden
Marcus Brinkmann              GNU    address@hidden

reply via email to

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