[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 8 Sep 2012 07:53:49 -0700
From: Isaac Dunham <idunham@...abit.com>
To: musl@...ts.openwall.com
Subject: Re: documenting musl
On Sat, 8 Sep 2012 12:44:33 +0100
Justin Cormack <justin@...cialbusservice.com> wrote:
> Sounds good. Happy to help. Have you got a model for what form it
> might end up in? I find that it helps to know how it might end up
> looking in order to get an idea of how much to write, and who the
> audience is.
Plan for mostly programmers/distro developers, with some regular
users who want to get something building.
At this point I'm thinking write plaintext, and we can add formatting
later.
> For example, do we want to produce a set of man pages for a
> distribution that uses Musl at some point? Should we aim to produce
> everything as an online reference first?
Most input formats can be converted to HTML. And that includes *roff.
linux-manpages-dev is documenting most linux libc versions as well as
portability issues, so it might make sense to just prepare patches that
will document where musl differs. But I'd suggest holding off until
0.9.5 is released to submit them, since there will be a few differences
in header behavior.
AFAICT, blowfish crypt, fgetln, strlcpy, and strlcat are the main
functions that stock glibc doesn't have. Manpages for those may be
helpful, since there aren't manpages for them.
> Maybe some examples will help to discuss what we want.
Perhaps look at the existing document on porting?
I think it's floating around on the list, and dates to ~0.9.3 (when
mips was merged).
> I think for the comprehensive documentation the wiki might be a pain.
>
> Justin
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.
