NO_MMU archs / relation to uClinux

[David McCullough]

Jivin Mike Frysinger lays it down ...
> On Wed, Mar 23, 2011 at 8:59 AM, Peter Mazinger wrote:
> > I have a testboard based on MCF5329 and have some additions
> > to support it in uClibc. Should I care here to get a bit support
> > (m68k without MMU) to build it or would one prefer to leave that
> > job to uclinux?
> >
> > It seems that many parts in the uClinux sources are not back/forward-ported
> > to uClibc (no_MMU related stuff, sensors, but also CPU specific options...).
> > Does anyone know the reason?

There is no hiding from it,  the uClibc in the uClinux-dist is old,  so yes,
there is sure to be a long list of new uClibc things that are not in there.
You should be able to take a current uClibc and drop it into the dist build
without too much drama,  especially if you already have a current version
you are familiar with and you know works.

Not sure what context "sensors" is in above,  uClibc or the kernel ?
The uClinux-dist kernel is very up-to-date.

> the uClinux.org guys are just very bad at pushing anything back
> upstream.

I would beg to differ :-)  We do what we can with the small resources we
have while making and supporting products to pay the bills.  We are not
the uClinux.org guys though,  that would be Arcturus, we are the uClinux-dist
guys that you talk about below, most known as SnapGear, though we have
officially changed company names more times than most can remember :-)

There are plenty of examples of large and small scale "push-back" from us
at various times to the upstream projects (ie., kernel, openssl, openswan,
gcc, binutils, pptp and yes, uClibc at one point).

As everyone knows (or should know) getting changes merged upstream can be
time consuming and tedious, depending on the project and the maintainers
and their particular goals.   We have limited resources and we choose our
fights.  The uClinux-dist releases are our way or reducing the load but
ensuring all the work we do is out there for people to find.

If you look back in time you will find we have contributed changes back to
uClibc in the past, but,  it was costing us.  We support a large number of
platforms/archs and each new version of uClibc was costing us weeks in
esoteric bugs and breakages.  We tried to reduce this by pushing back changes
but the directions of the two projects were obviously different at the time
and we couldn't afford the regular downtime,  so we settled on a stable
version with support for a broad range of platforms/arches and moved on.

> so dont rely on them sending anything at all.

We aren't in the business of submitting other peoples patches upstream and
have always made this obvious on the list when asked.  We will take patches
for the dist,  but will also recommend you push them upstream yourself if
thats the outcome you want.

> the uClinux
> distro is very much run as "suck in sources, patch it until it works,
> and then never touch again unless things break".  i dont know what
> their future even holds though considering the company developing it
> were taken over by mcafee purely to buy up the competition and squash
> it.

I can assure you that the small core that is left is still busy,  though we
are quite short on resources we will continue to do what we can.  It just
means our efforts have become more focused.

> so if you want something fixed, you'll need to integrate it yourself.

This has always been the case with OSS,  you can ask,  but if no one
has the answer or a fix then it's up to you.  We help a lot of people with
problems outside of our space,  but you can't expect or demand it.

Peter,  if you have problems specific to the Coldfire MCF5329/uClinux-dist
support you might find some people who can help you out on the uClinux-dist
mailing list,  it's worth a shot,

Cheers,
Davidm

-- 
David McCullough,      david_mccullough at mcafee.com,  Ph:+61 734352815
McAfee - SnapGear      http://www.mcafee.com         http://www.uCdot.org