Hi Jamie,
Jamie Lokier wrote:
Thanks for your reply, Doug.
Doug Kehn wrote:
The subtle difference is with '*big*'. The link
without '*big*' is for non-MMU targets. The link with
'*big*' is for MMU targets (it may also have non-MMU
in it too).
That is subtle. I have to wonder why not '-nommu' and '-mmu' if
that's the difference :-)
The patch sets are designed for different things.
The standard issue -uc patch set is the set of patches I
am considering submitting to Linus for inclusion in main-line
kernels. The will only contain mmu-less (uClinux) specific
changes that I normally look after (or at least that have
been submitted to me to push up to Linus).
Now the big patch set will contain all of the aboove and a
lot of extra stuff that makes the kernel more useful within
the context of using it with the uClinux-dist package. It
will contain both mmu-less and mmu architecture changes.
It will include lots of drivers, and lots of other stuff
(some of which will never go near main line kernels :-)
The names are historical. The -uc is ofcoure uClinux
specific, so that is not so bad. "big" is the additional
suffix I happened to add when I first made this bigger
patch set.
Are there other differences between the patches, e.g. features, driver
patches etc.?
Yes, very substantional differences.
In other words, should I use the -big one even though I've got a
no-MMU device?
Sure, if you are using the uClinux-dist I would think that is
probably what you want.
I'm working on some Sigma Designs no-MMU ARM devices, and I'm taking a
(very) tentative look at porting the code from 2.4.26 to a 2.6 kernel.
Most of Sigma's code is proprietary, but their big kernel patch and
some drivers are GPL, and it seems feasible to port it.
But there's a lot of changes from 2.4 to 2.6, and the recent messages
about 2.6 no-MMU ARM support being virtually non-existent suggest it
might be a lot of work.
Well that is certainly not true. I use non-MMU ARM in 2.6 all the
time. But it is not in mainline. The big patch has support for the
Atmel/AT91x40 (in the guise of the GDB/ARMulator). But outside of
that you will need to do support for your specific ARM core.
Regards
Greg
------------------------------------------------------------------------
Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED]
SnapGear -- a Secure Computing Company PHONE: +61 7 3435 2888
825 Stanley St, FAX: +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com
_______________________________________________
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
