[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120907233658.2eb8ee1a@newbook>
Date: Fri, 7 Sep 2012 23:36:58 -0700
From: Isaac Dunham <idunham@...abit.com>
To: musl@...ts.openwall.com
Subject: Re: documenting musl
On Fri, 7 Sep 2012 22:40:06 -0400
Rich Felker <dalias@...ifal.cx> wrote:
> Hi all,
>
> One item that's been on my todo list for a while, but didn't really
> make it into the last email, is creating some kind of documentation
> One document, which I would call simply the "manual", should cover
> everything you need to know if you're writing applications against
> musl or building existing applications against musl. It should contain
> introductory materials on the standards and extensions musl aims to
> support, feature test macros, etc. It should also document musl's
Just wrote up a preliminary draft for this part.
> locale behavior, quality of implementation guarantees, and anything
I'm not certain about these, myself.
> ISO C or POSIX requires an implementation to document (i.e.
> implementation-defined behavior). In some cases, the documentation may
> defer to that for the compiler being used. The manual should further
> document any additional behavior guarantees for functions beyond
> what's required in the standard, as well as behavior for all supported
> non-standard functions.
>
> A second possible document would be oriented towards people wanting to
> learn from the source, port musl to new platforms, add features or
start with the "Porting" docs?
> customize it for unusual usage cases, reuse parts of musl in other
I presume this includes (for example) builds without src/complex/ and
stripping it down for embedded use? I've been doing a few experiments
in that way.
> software, etc. This document would explain the source tree layout and
> build system, use of weak symbols and object file dependency graph
> issues, stdio and pthread internal interfaces including thread
> cancellation architecture, porting requirements, and so on.
> Ideas? Volunteers?
I can do some of this.
I'm thinking about turning some of these into man pages.
eg, musl-standards, musl-features, musl-porting, musl-implementation...
Also, manpages for functions not covered by linux-manpages-dev (fgetln,
strl*, ...) _might_ be in order.
View attachment "musl-man.txt" of type "text/plain" (2200 bytes)
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
