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

[Robert L. <rm...@te...>]

On Fri, 2001-12-07 at 08:40, NIIBE Yutaka wrote:
> 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. 

This is very good.  I would be happy to help you or otherwise work on
it.  What is needed, as dwmw2 pointed out, is an API like this to handle
all the arches needs.

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

I won't do anything without your blessing.

However, a couple ideas: we need to realize that the above is a
2.5-thing, and could take a _very_ long time to design, implement, test,
and finally have merged.  In the mean time, SH will grow further and
further out of sync.

I propose we work on the above API.  In the mean time, lets sync the
trees.  We do _not_ have to include the code you don't want. 
Possibilities:

(a) Don't send anything for mm/memory.c -- in our tree, keep it if'ed
out.  In the official tree, keep it as-is.  This means we keep the
reminder, we don't have the needless code, and the official tree doesn't
see anything yet.

(b) Implement the API for just that one file.  Something like:

#ifdef CONFIG_SH
#define flush_cache_page_xxx(a, b)
#elif /* arches that need it */
#define flush_cache_xxx(a, b) flush_cache_page(a, b)
#endif

where xxx is this specific use of the cache flush.

I think the ideal solution for the API is something like
include/asm/cache_policy.h

where the proper uses of the various cache flushings are defined as
needed.  Obviously we can't do that just yet...but the above is
essentially the same thing.

(c) just merge choice parts.  for instance, merge our changes to 8139too
to the maintainer (and have him merge the changes to Linus/marcelo). 
8139too is changing and its going to break our patches.

> 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.

I understand.  What we disagree about is that we can't work around the
issue for the time-being.  From above, I think (a) and (b) offer the
ability to synchronize our tree, but for our CVS repository to keep the
development changes.  We work on the new API there, and we can send a
solution to the official 2.5 tree when that time comes.

At least, do this for 2.4 ... but even with 2.5, things will get
progressively out of sync and we should send _some_ stuff out.

> 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.

Honestly, that is terrible :)

I hope we don't grow out of sync for two years ...

>  > 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.

Agreed, you have a very good foresight and understanding of maintenance.

Please consider the suggestions above.  Let's synchronize things as much
as possible.  I agree we have a maintenance issue with the cache flush
stuff -- let's not touch that now, then.  We can leave it as-is and we
will fix it in due time.  The CVS tree will remain if 0 or whatever API
we begin to work on.

Remember, there is already SH work in the official kernel.  We are just
bringing it further up to date.  Cache issue is no better there, either
...

	Robert Love