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.