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