Hi Jamie,
Jamie Lokier wrote:
Greg Ungerer wrote:
Now that generic nommu support is _nominally_ in the mainline kernel,
it seems odd to me that the mainline kernel + SoC patches is not what
I'm supposed to be doing.
That is your starting point. Ideally when you are happy with your
specific SoC support you generate patches and we can get them
merged into mainline.
I wasn't necessarily thinking of merging all SoC patches into
mainline. I was rather thinking to publish those SoC patches, as
required by the GPL, in the same way as other GPL required sources for
a firmware release. After all, you don't merge every quirky little
board-specific driver in, do you (/dev/my_front_led)?
Or is the '2.6 way' more radical than that, asking for everything to
be merged in as a config option? I could do that, if it's truly
wanted.
Reality is most people don't mainline everything - it is a lot
of work. But you can, and some people do.
Is it the long term goal that a system developer would, eventually,
get the mainline kernel + their own SoC patches and that should be
sufficient - as it is with many of the architectures already?
I would hope the long term goal is to get your full SoC support
into the mainline kernel. Yes it could take quite some work to
do this.
I don't mind, the work can be incremental. As long as I know the
intention is there, I can feed the process.
(Getting -ucN or -rmkN or whatever patches to try things before they
are merged and so on is different, I'm not asking about that, I'm
asking if the intention is that everything which isn't
board/SoC-specific will be merged into mainline at the usual rate and
methodology for other (non-uclinux) architectures?)
In a perfect world everything would be mainlined.
Well, given time for some things. You still have Ingo's tree, Andrew
Morton's tree, etc... there is still a pipeline for more contentious
patches. But, yeah, they do get there fairly quickly if they're not
contentious.
Thats right. The thing to remember is that Ingo's and Andrews trees
are the stepping stones to the mainline. They are part of the mainline
process - not independent of it.
This may seem like an odd question, but I have been under the
impression that, at least for 2.4 kernels, both yourself and Russell
King believed in not keeping all the essential uclinux/ARM patches in
mainline kernels. So I guess I can summarise: has that policy
changed, to be more in keeping with general 2.6 development practice?
Absolutely. The goal is mainline everything. With 2.4 there was
no core non-mmu support for anything. It made no sense to mainline
non-MMU architecture code with no core support.
But wasn't it drivers too, not just architecture code? Anyway, that's
all history. (Though, for now, like a lot of people I'm stuck on
2.4.26 or so until we get 2.6 working....)
Sure, drivers are part of the equation too.
With 2.6 I/we are trying not to live outside mainline with large
patchsets. The patch sets are for testing and evaluation, to get
the code right before submission.
Hope that helps...
It helps a lot, thanks very much. That gives me a lot of optimism.
I'm used to working with mainline kernels core code, and tracking and
using new features close to their creation, so I'm really pleased that
uClinux kernel development is converging to that model too.
Thats the plan :-)
It is working reasonably well for the m68knommu, blackfin, etc.
Hopefully I will find the time, energy and motivation to port my ARM
no-mmu SoC support to 2.6, and in doing that help move generic ARM
no-mmu support closer to mainline. Btw, I've already had a response
off-list from someone else working on the same devices as me, who
wants to do the same thing, so that's getting more plausible.
Thanks very much for your response, Greg, it was very helpful and
exactly what I was hoping for.
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
