Problem building BB 1.2 daemons for uClinux ARM

Rob Landley rob at landley.net
Tue Aug 29 16:13:36 UTC 2006


On Tuesday 15 August 2006 5:06 am, Ian Oliver wrote:
> In article <44E0969B.1010507 at bfs.de>, Walter harms wrote:
> > #if defined(__UCLIBC__) && !defined(__ARCH_HAS_MMU__)
> > #define daemon    clone
> > #endif
> > 
> > since clone() is a syscall it should work even wenn !defined(__UCLIBC__)
> > can you please check it ??
> 
> OK, I'll try and see if this works. But I've found other old messages 
> where people submitted patches to get telnetd going on NOMMU uClinux but 
> they don't seem to have been merged.

How old are we talking?  About 4 months ago I got a big mega-patch that 
applied to 1.0.0-pre something, which was virtually unusable.  Keep meaning 
to go through and cherry pick stuff, but at the time I didn't have a test 
environment for nommu and it's composted a bit in my to-do heap at this 
point.

At OLS I finally got a test environment via software emulation, but I haven't 
had a chance to seriously play with it since.  And somebody's mailing me a 
blackfin board but it hasn't arrived yet.

> I'm not sure I know enough about the status/direction of BusyBox support 
> for MMU-less uClinux systems to know how best to proceed.

I'm interested and want to see it work.  Unfortunately, I have some 
higher-priority structural issues to deal with first, and some largeish 
cleanups I'm trying to get in for the 1.3.0 release.

One global cleanup that I'm working on is merging each applet's static 
variables into a struct, and making a union of all those structs.  This has 
two big advantages: 1) much easier to make our applets re-entrant for nofork 
bbsh and such, 2) friendlier to nommu, and a few smaller ones.  
Unfortunately, the hard part is fiddling with the build infrastructure so we 
don't have to maintain yet another applets.h/usage.h style header file by 
hand.  (I think I know what to do, hit it with the hammer of sed from the 
makefile ala libbb/xfuncs.c to dynamically create said header, but I haven't 
done it yet.)

> I guess I could just be happy that I now have a working solution. :-)
> 
> Ian

Rob
-- 
Never bet against the cheap plastic solution.



More information about the busybox mailing list