Re: [linuxsh-dev] Linuxsh / Vanilla policy? - General question

[Paul M. <le...@li...>]

On Mon, Aug 28, 2006 at 08:12:34AM +0900, Kaz Kojima wrote:
> The merging linuxsh local stuff to the vanilla one requires
> the approval from kernel folks.  This is not easy mainly
> because their top priority is what will be best for the primary
> targets like IA32 or x86_64 machines.  Yes, linux has a good
> scalability over wide spectrum of targets, but the core
> interest of the development is not in embedded processors.
> I won't complain for it.  I think it's very reasonable attitude
> to maintain such a big project with huge users.
> Now we have far less linuxsh patches which might affect
> the generic codes, thanks to Paul, but it isn't easy to make
> it zero.
> The situation for other embedded processors might be better
> than SH, but essentially same, I think.  For example ARM,
> perhaps some vanilla kernels will boot on some boards, but
> it seems that almost ARM people use the ARM specific patch in
> ARM linux site.
> 
This has changed recently, ARM is primarily working on kernel.org
directly, though there are still patch queues and development trees on
the side that still follows the out-of-tree and occasional sync-up
methodology that we've been using for years. Now that we're a lot more
in sync with mainline in the generic bits, it's probably worth
considering a switch of focus and developing on current git directly. We
did this partially in 2.4 with BK also, for some of the SH4-202 and
Microdev work.

It's also not too useful to be developing our own APIs temporarily,
hashing them out on linux-kernel until they're merged, and then updating
our local versions after the fact (for instance, the lib/bitmap rework
we needed for the store queue changes), focusing on current git will cut
down on these delays quite a bit.

The rate of change is very high, both in Linus's tree and in ours, and
trying to sync these up during the merge window leaves us with a huge
number of fairly large patches. From a maintenance point of view, it's
becoming increasingly more time consuming to maintain the tree against
anything other than current git, especially as we spend a lot of time
playing API catch-up around the time the merge window opens up.

With things like sh64 this is not that much of a problem, since the rate
of change is very low in the architecture backend. We've been more or
less using kernel.org releases out of the box there for well over a year
now, with very few changes required to keep it going.

So given that, yes, my goal is to switch the SH tree to working on the
current git directly, and we'll probably start working towards that
after a fairly large resync once 2.6.19 opens up. If we maintain a pull
tree, it's also fairly trivial to have new changes pulled in to -mm for
those that want to play with the new things without waiting on Linus's
tree. This will also force those people doing driver development to do
it in a more visible location, and get more immediate feedback from
subsystem maintainers, rather than waiting for me to get around to
pushing out subsystem updates.

This also means that those wanting to pull the new features and support
we're implementing in to a stable cut-off point will have a harder time
of backporting (or be forced to switch to current git). While this is
something that the embedded vendors aren't going to like, it's really
the only way to go forward and to sanely handle the rate of change.
Those wanting new features will have to stick with backporting or
waiting for a new release.