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. > >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. > >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....) > 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. 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. -- Jamie _______________________________________________ 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
