Re: [linuxsh-dev] Drop-In tree updates

[NIIBE Y. <gn...@m1...>]

Robert, thanks for your offering help.

My idea is like following for the cache handling.  I think that it
would be the things for 2.5 because it includes API change.

  (1) Think about API (set) of cache handling for 2.5.
  (2) Propose new API to lkml, ask review from another arch people, 
      possibly with example API changes to some archtectures including
      SH.
  (3) When it will be applied to mainline kernel, we can remove
      ugly #if-0-outed line from LinuxSH kernel of 2.5.
  (4) Backport the API change if it's really stable. 

If you want to do this, I don't stop you.  But could you please not
to send #ifdef CONFIG_SUPREH version to mainline.

			*	*	*

Changes in generic code requires time, occasionally _much_ time to
synchronize.  I'd say, be patient.  For me, in some cases, it takes a
year or so.

One good example is a cache flush at swaping code.  It has been wrong
for a long time for some architecture.  I did put some work around for
SuperH in 1999.  Some time later, I've found a proper fix, then I've
proposed the changes last year.  At that time Dave Miller agreed the
fix as some Sparc chip has same issues.  However, it does not get in
for a half of year.  Then, MIPS people foundd same issue, and I resent
a patch, which finally got in.  I needed to maintain it over a year
before it got merged.

 > Maintaining a divergent tree makes things harder on everyone.  It makes
 > syncing on our end harder.  It causes changes to the kernel with no
 > regard to what we are doing (since no one knows). Etc etc ...

I don't say divergence is good thing.  I say we need to maintain
divergence.  If we have changes in generic code, we need to maintain
the divergence, because it is very difficult to get merged.

Because it is hard to maintain divergence, we need to take care.
--