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: embedded newbies site.
Date: Sun, 21 Jul 2013 23:40:11 -0500	[thread overview]
Message-ID: <1374468011.3719.27@driftwood> (raw)
In-Reply-To: <CAL3m8eDFTf=sx9GSH06XiY_1VLNERuWZFuUECczkP4scv97WsQ@mail.gmail.com> (from strake888@gmail.com on Mon Jul 15 22:18:20 2013)

On 07/15/2013 10:18:20 PM, Strake wrote:
> On 15/07/2013, Rob Landley <rob@landley.net> wrote:
> >    - creating a development environment (building binutils, gcc,
> > make...)
> >      - requirements for self-hosting
> >      - requirements for natively building Linux From Scratch
> >      - cross vs native compiling
> >        - bootstrapping to native compiling under emulation.
> 
> This. For me, at least, this is often the greatest hindrance.

It's a fairly hard part. My whole aboriginal linux project was an  
investigation of what's actually involved here and how to do it. Now  
that the investigation's complete (or at least reached a reasonable "it  
works now, and I can't think of an obviously better wya to do it with  
the tools at hand" stopping point), I suspect there's a better way of  
explaining it than just "go read this giant pile of shell scripts that  
I got to work".

So I should write up what's involved, and how I determined the  
requirements...

> > - efficient (elegant) programming
> >    - Why C and scritpting languages, why NOT C++ and autoconf
> >    - tradeoffs
> >      - code reuse
> >      - transaction granularity
> >      - taking advantage of SMP without going crazy
> 
> I would be glad to help here.

What did you have in mind?

> May find some ideas here:
> http://harmful.cat-v.org/software/

I read the original "cat -v considered harmful" which is why I did  
"catv" in busybox many years ago, but that was a paper by one of the  
original bell labs guys. This guy is just collecting random papers.

While I admire the attitude, I've never found that site particularly  
useful. There's no pragmatism at all in his approach, he doesn't  
recommend things you can actually _use_, just platitudes. He recommends  
tcc instead of gcc, which doesn't build even 1% as many real world  
software packages. (I joined the tcc mailing list right after tccboot  
hit slashdot circa 2004, and I spent 3 years maintaining a tcc fork  
after Fabrice moved on to QEMU. I know exactly why it's NOT a real  
world replacement for gcc right now, what would be required to get  
minimal functionality out of it, and why the current development team  
will never do so.) Similarly he recommends uclibc and dietlibc instead  
of glibc with no discussion of the tradeoffs... musl exists because  
they're not good enough.

What I'm hoping out of the new embedded newbies stuff is things people  
can actually do/use. Even the theory should lead to practical advice,  
immediately applicable. (It just explains _why_ you want to do it that  
way, and what happens if you don't.)

Rob

  parent reply	other threads:[~2013-07-22  4:40 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-16  2:03 Rob Landley
2013-07-16  3:18 ` Strake
2013-07-17 12:07   ` LM
2013-07-17 13:58     ` Rich Felker
2013-07-20 15:17   ` James B
2013-07-22 12:27     ` Andrew Bradford
2013-07-22  4:40   ` Rob Landley [this message]
2013-07-23  0:12     ` Strake
2013-07-27  0:58       ` Rob Landley
2013-07-27  2:01         ` Strake
2013-07-27  2:50           ` Rich Felker
2013-07-29 20:01             ` Rob Landley
2013-07-29 19:54           ` Rob Landley
2013-07-30  1:35             ` Strake
2013-08-01  6:20               ` Rob Landley
2013-08-03 16:52                 ` Strake
2013-07-16 11:50 ` LM
2013-07-16 13:56   ` Szabolcs Nagy
2013-07-16 14:00   ` Rich Felker
2013-07-16 17:49   ` Strake
2013-07-22  6:00   ` Rob Landley

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=1374468011.3719.27@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).