[BusyBox] Compiling busybox with newlib [PATCH]

[Rob Landley]

On Friday 04 March 2005 12:01 pm, Shaun Jackman wrote:
> On Fri, 4 Mar 2005 10:13:31 -0500, Rob Landley <rob at landley.net> wrote:
> > What are "embedded targets of the non-kernel variety"?  What, they run
> > DOS?
>
> I didn't mean the system doesn't run the Linux kernel -- although
> that's true as well. I meant the system runs *no* kernel, not DOS, not
> nothing.

Then you have no I/O devices.

Any library for performing I/O and memory management which talks directly to 
the hardware is, in the absence of any underlying layers, acting as a kernel.  
Since busybox doesn't have any gorp built in to handle interrupts or bang on 
I/O ports, I'm assuming you're binding it to something that does.

Is newlib handling banging on the I/O ports to talk to your serial terminal, 
or is it talking to some underlying layer?  If so, that underlying layer is 
your kernel.

> The embedded system runs a single binary in a single process. 

DOS did this too.  It was still an OS, it still had a kernel.

> The single binary is busybox, which is stored in the bootsector of
> flash, and the system boots to newlib's _start which calls busybox's
> main, thus starting the single process.

What I/O devices do you have?

> newlib supports SUSv2 and many POSIX extensions. I only submitted
> patches against code snippets that #include <linux/*> or #include
> <asm/*> which are by definition non-portable.

I'll look at it again this evening to see if we can make any of the stuff 
you've identified more portable in general.  I know that the loop.c thing is 
a mess I've tried to address before, but your patch made the tumor _bigger_.

Query: are you doing loopback mounts?  If so, then we don't need to fix 
loop.c, what we need to do is fix the build so that it can tell that loop.c 
is only needed when you build losetup or mount/umount with loop support.

> Cheers,
> Shaun

Rob