[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20121204214522.GJ20323@brightrain.aerifal.cx>
Date: Tue, 4 Dec 2012 16:45:22 -0500
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: Summary of 1.0 marketing plan/scheme/nefarious plot from
IRC.
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.
> 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.
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. 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.
> 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. 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.
> 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.
> it). Dynamic vs static linking, "what is a dynamic linker and wazzit
> _do_". Something on the whole "how to tell if your binary is built
> against musl or some other libc, how to tell if it's statically or
> dynamically linked" (fun with ldd and readelf -a), long ago I wrote
> an intro to cross compiling if that's worth linking to... Stuff.
Yes, the "how to tell what libc a binary is linked against?" is
actually a really good FAQ topic (a question that really arises
frequently).
Rich
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.
