From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/2407 Path: news.gmane.org!not-for-mail From: Rob Landley Newsgroups: gmane.linux.lib.musl.general Subject: Re: Summary of 1.0 marketing plan/scheme/nefarious plot from IRC. Date: Tue, 04 Dec 2012 18:58:21 -0600 Message-ID: <1354669101.27682.9@driftwood> References: <20121204214522.GJ20323@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; DelSp=Yes; Format=Flowed Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1354669120 24942 80.91.229.3 (5 Dec 2012 00:58:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 5 Dec 2012 00:58:40 +0000 (UTC) Cc: musl@lists.openwall.com To: musl@lists.openwall.com Original-X-From: musl-return-2408-gllmg-musl=m.gmane.org@lists.openwall.com Wed Dec 05 01:58:50 2012 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1Tg3K5-00009N-RP for gllmg-musl@plane.gmane.org; Wed, 05 Dec 2012 01:58:50 +0100 Original-Received: (qmail 1341 invoked by uid 550); 5 Dec 2012 00:58:37 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 1331 invoked from network); 5 Dec 2012 00:58:37 -0000 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:subject:to:cc:in-reply-to:x-mailer:message-id :mime-version:content-type:content-disposition :content-transfer-encoding:x-gm-message-state; bh=/qDTFfuoWAdqyLPYItnx3p6FfR2lsCIe0unBhtUz3G0=; b=Y4hcz9wS7Zy/KDSbWDfqArzku4W2owGGGS0s8sFWVJ/QdFEizPdeoBgpkU+zPYh0Lg 74Pxl9gnBdBGW4FOqQKFuIMgfUpsImNv6NJoVbIdYF3wRGl7vvSmc3V//I1hv3rTUQy9 tOKoHkcO4+NsA9nnBDM5qHs1wxIvXwIUJB0CIdeISvXexQp/OVruJMixK426FcFpC+9q sZgduWj8ofxuRPSW7JzRXmfbOYr5HFd5cnX5I+UwIgvlB+7j5sbDObBfsP2w07ZZSsTd PEJAf9ikVItGYRhlxtxkihBJrPBXX+DK6plyM8wSo3evXUAWP6sAz824GALO33jzi5II W39A== In-Reply-To: <20121204214522.GJ20323@brightrain.aerifal.cx> (from dalias@aerifal.cx on Tue Dec 4 15:45:22 2012) X-Mailer: Balsa 2.4.11 Content-Disposition: inline X-Gm-Message-State: ALoCoQmG3Nhdp4TROMW98Tjm0h8CoS8gjeXLp0selU0uRNA6/dNAkQXjNfR/rBLFj0C9pl0ZhYVo Xref: news.gmane.org gmane.linux.lib.musl.general:2407 Archived-At: 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 =20 > 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 =20 > "copyleft" > > >licenses, where the former basically allow you to do whatever you > > >like, and the latter burden you with ensuring that the parties who =20 > 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 =20 > level > > >> license and call all the code "compatible" with that, and then =20 > 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. >=20 > 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 =20 "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 =20 the "where do I go next" hurdle when people glance at the page but =20 aren't actually hooked yet. (I don't want to require a decision out of =20 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? >=20 > 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). >=20 > 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 =20 through /bin/sh (unless you set SHELL), and it's easy to =20 leak/{bashisms,in,there} if you're not careful. :) But if it builds on systems with the Defective Annoying SHell as =20 #!/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). =20 Let's see, 2.6.0 was 2003 and knoppix 3.6 was 2004... and is using =20 2.4.27. (I vaguely recall that distros were reluctant to move to 2.6 =20 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 >=20 > 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. >=20 > > - c99 compiler with support for gcc-style assembly language. >=20 > I'm actually hoping to make the gcc-style inline asm optional at some > point, but for now, it's required. >=20 > > 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.) >=20 > 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. >=20 > > 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. >=20 > 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 =20 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 =20 two different roles in mind, tutorial and reference. A great reference =20 isn't always good to learn from, and the thing you learned from can be =20 horrible to try to look something up in afterwards. It's possible for =20 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. >=20 > 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. >=20 > > 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".) >=20 > 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 >=20 > 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 =20 refspecs.linuxfoundation.org (although you need to read the base spec =20 _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=