mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rob Landley <rob@landley.net>
To: musl@lists.openwall.com
Cc: musl@lists.openwall.com
Subject: Re: Summary of 1.0 marketing plan/scheme/nefarious plot from IRC.
Date: Tue, 04 Dec 2012 18:58:21 -0600	[thread overview]
Message-ID: <1354669101.27682.9@driftwood> (raw)
In-Reply-To: <20121204214522.GJ20323@brightrain.aerifal.cx> (from dalias@aerifal.cx on Tue Dec  4 15:45:22 2012)

On 12/04/2012 03:45:22 PM, Rich Felker wrote:
> On Tue, Dec 04, 2012 at 02:48:53PM -0600, Rob Landley wrote:
> > On 11/30/2012 10:06:20 PM, Rich Felker wrote:
> > >On Fri, Nov 30, 2012 at 08:04:44PM -0600, Rob Landley wrote:
> > >> >>      - already tested against 8 gazillion packages
> > >> >>      - standards compliant
> > >> >>      - BSD license: static linking ok, android deployment ok
> > >> >Little quibble: MIT + some BSD and some PD code.
> > >>
> > >> Alas, we don't have a good group term like "copyleft" for "would  
> be
> > >> public domain if our legal system wasn't screwed up".
> > >
> > >We do have a word for this license class; it's called "permissive".
> > >Roughly speaking, "FOSS" breaks down into "permissive" and  
> "copyleft"
> > >licenses, where the former basically allow you to do whatever you
> > >like, and the latter burden you with ensuring that the parties who  
> get
> > >the software from you get the same freedoms you had.
> > >
> > >> I poked Dalias on irc to clarify that we can give a single top  
> level
> > >> license and call all the code "compatible" with that, and then  
> link
> > >> to the big long copyright list for everybody who cares but have a
> > >> clear story on the website.
> > >
> > >The MIT license text serves this purpose.
> >
> > At some point we might want to collate edits to the original list.
> >
> > More suggestions:
> >
> > The musl-libc.org main page should probably just go to the "intro"
> > page, possibly with the existing paragraph merged into the entro.
> 
> I feel like the current contents of the "intro" page are a bit verbose
> for a main/landing page, but I'm open to other views on this.

Something I tried to do on the aboriginal linux about page was have a  
"what is it?" box that drew the eye.

   http://landley.net/aboriginal/about.html

I dunno how _successful_ I was, but that was the intent. It bypasses  
the "where do I go next" hurdle when people glance at the page but  
aren't actually hooked yet. (I don't want to require a decision out of  
anybody quite that early. :)

> > The "what are musl's dependencies" faq entry is a mix of bullet
> > points and non-bullet point material that doesn't just clarify the
> > bullet points. It doesn't mention what "make" you need (posix-2008
> > compliance should be enough?) and the shell is implicit (does _not_
> > need bash, posix-2008 again good enough?). Did we actually test
> > Linux 2.6.0?
> 
> Make needs to be GNU make or compatible. Writing makefiles for POSIX
> make is an exercise in wasting maintenance time; there's no way to
> write general or wildcard based rules. As far as I know, it should
> work even with ancient versions of GNU make (pre-GPL3), and would
> probably work with a minimal clone of GNU make (but GNU make itself is
> already very light and portable).
> 
> Shell is not really required at all since you can write your own
> config.mak based on the sample one. Configure is intended to require
> just POSIX sh, not anything from bash; I've never even used it with
> bash myself.

Make calls sh. All those "rm -rf" entries under clean: get washed  
through /bin/sh (unless you set SHELL), and it's easy to  
leak/{bashisms,in,there} if you're not careful. :)

But if it builds on systems with the Defective Annoying SHell as  
#!/bin/sh, that probably covers it.

> I have not tested it with Linux 2.6.0, but based on man syscalls,
> 2.6.0 has all the functionality needed for programs that don't use
> POSIX 2008 functionality to work.

My "old" regressino test is a Red Hat 9 kvm image (2.4.20 kernel).  
Let's see, 2.6.0 was 2003 and knoppix 3.6 was 2004... and is using  
2.4.27. (I vaguely recall that distros were reluctant to move to 2.6  
and basically didn't until around 2005...)

> 2.6.16 is needed for the "*at"
> interfaces, and a number of signal-related bugs were fixed in 2.6.22,
> so if you don't want to work around kernel bugs, I think 2.6.22 is the
> earliest kernel anybody should actually be using.

Probably good to document this then.

> > Hmmm... something like:
> >
> > -----
> > Compiling and linking programs against musl should work with any
> > conformant C compiler.
> >
> > To build musl itself, you need:
> >
> >   - Linux 2.6 or later
> 
> Linux is not a build dependency. You can build musl just fine on any
> machine with a gcc targetting the ISA/ABI you want musl to run on.
> 
> >   - c99 compiler with support for gcc-style assembly language.
> 
> I'm actually hoping to make the gcc-style inline asm optional at some
> point, but for now, it's required.
> 
> > It would be nice if there was some kind of "musl manual". If you
> > want to write a program against the musl libc, what does it provide?
> > (HTML is fine, man page format is kinda archaic these days. This is
> > mostly posix, but not entirely.)
> 
> Yes, this would be covered in the proposed manual, an outline for
> which I posted to this list a couple weeks back. Right now I'm leaning
> towards having it be my main project between the last 0.9.x release
> and 1.0, to have a major addition for 1.0 (the manual) without the
> risk of regressions from major code changes.
> 
> > If we're not up to writing something, w link to the POSIX spec with
> > the list of functions we've implemented, plus the man7 pages on the
> > linux variations thereof (and system calls) and maybe the Linux
> > Standard Base sort of collectively covers it.
> 
> Basically, my idea is that the manual will "defer to POSIX and ISO C"
> on functions specified by them, with specific notes on extended
> behavior in these functions beyond what the standards require.

I'm thinking a resource for people writing code. Somewhere they can  
look up "what knobs do I have a available and what do they do?"

When writing (or indexing) documentation I find it useful to keep the  
two different roles in mind, tutorial and reference. A great reference  
isn't always good to learn from, and the thing you learned from can be  
horrible to try to look something up in afterwards. It's possible for  
one thing to do both, but at least twice as hard.

> For
> nonstandard functions, early versions of the manual will probably
> provide a list of what's provided with notes wherever they differ
> significantly from the GNU or BSD functions they're modelled on. Later
> we could expand this documentation to actually cite the relevant BSD
> or Linux man pages.
> 
> In addition to this, certain functions in the standards have
> implementation-defined behaviors, which means an implementation is
> required to document what behavior it provides. One thing we should
> definitely document is iconv and locale behavior. Compiling a complete
> list of the implementation-defined behavior musl needs to document
> would be a good project someone could help out with between now and
> 1.0.
> 
> > Beyond the FAQ, there should probably be a page introductory docs. I
> > generally link to the old boot floppy howto, the power up to bash
> > prompt howto, and Linux From Scratch. (We could always write
> > something new, but this is more "understanding how your root
> > filesystem works" and "creating a small distro" than "how libc
> > works".)
> 
> Sounds useful.

http://www.tldp.org/HOWTO/Bootdisk-HOWTO/
http://www.tldp.org/HOWTO/From-PowerUp-To-Bash-Prompt-HOWTO.html
http://www.linuxfromscratch.org/lfs/view/stable/

> > More conceptual intros: what is ELF (with a link to the specs and
> > mention of alternatives like #!/interpreters, binflt, binmisc, and
> > historical a.out) also WHY is ELF (it's an archive format for binary
> > code, about as flexible as tar or zip but with metadata about
> > function names, offsets, and permission bits instead of
> > files/lengths/owners, generic enough that binflt is created from
> 
> ELF does a lot of things. Your description is somewhat accurate for
> ELF object files, but for an ELF program file or shared library, the
> only part of the file that's actually used is basically sequence of
> instructions for mapping the file into memory, adjusting memory
> permissions, and possibly performing relocations and symbol
> resolution.

I also didn't mention the difference betwee .o, .so, and exe files. :)

There's a linkers and loaders book online, and an actual ELF spec on  
refspecs.linuxfoundation.org (although you need to read the base spec  
_and_ a target spec to get anything useful).

http://www.linuxjournal.com/article/6463
http://www.iecc.com/linker/

http://www.linuxjournal.com/article/1059
http://www.linuxjournal.com/article/1060
http://www.muppetlabs.com/~breadbox/software/tiny/teensy.html

Rob

  parent reply	other threads:[~2012-12-05  0:58 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-30  2:21 idunham
2012-12-01  2:04 ` Rob Landley
2012-12-01  4:06   ` Rich Felker
2012-12-01  8:18     ` Isaac Dunham
2012-12-04 20:48     ` Rob Landley
2012-12-04 21:45       ` Rich Felker
2012-12-04 23:01         ` Isaac Dunham
2012-12-04 23:22           ` Rich Felker
2012-12-05  0:58         ` Rob Landley [this message]
  -- strict thread matches above, loose matches on Subject: below --
2012-11-29 20:50 Rob Landley
2012-11-29 21:15 ` Justin Cormack
2012-11-29 21:51   ` Luca Barbato
2012-11-30  1:30   ` Rich Felker
2012-12-01  0:04     ` Rob Landley
2012-11-30  9:21   ` Rob Landley
2012-11-30 11:08     ` Szabolcs Nagy
2012-12-01  2:00       ` Rob Landley
2012-11-30  1:27 ` Rich Felker
2012-11-30  8:11   ` Truls Becken
2012-11-30 14:29   ` Luca Barbato
2012-11-30 19:05     ` Rich Felker
2012-11-30 20:16       ` nwmcsween
2012-11-30 20:20         ` Rich Felker
2012-11-30 20:32           ` nwmcsween
2012-11-30 20:25       ` Szabolcs Nagy
2012-11-30 20:26         ` Rich Felker
2012-11-30 21:14           ` Luca Barbato
2012-11-30 21:26             ` Rich Felker
2012-12-01  0:04   ` Rob Landley
2012-11-30  4:38 ` Jens Staal
2012-11-30  7:08   ` Daniel Bainton
2012-11-30 13:26 ` Hiltjo Posthuma

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1354669101.27682.9@driftwood \
    --to=rob@landley.net \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).