linuxsh-dev

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

Re: [linuxsh-dev] Re: Slow 32 bytes long "mov" delta - Hitachi SH4(7750),SolutionEngine(MS7750SE01E)

[Vladimir D. <vdo...@wa...>]

2.4.5

kaz Kojima wrote:
> 
> Hi,
> 
> Vladimir Doukhanine <vdo...@wa...> wrote:
> > If I copy data from one place to another after each megabyte (delta
> > between src and dst)
> > there is some kind of "black hole" 32 bytes long in which processor
> > works 15 times
> > slower.
> 
> Which version of kernel are you testing?
> 
>         kaz
> --
> BTW, I've replied to your mail and it returned with Host unknown
> error (Name server: wann.com: no data known). It seems the problem
> of my ISP. Anyway, please write to the mailing list, not to me :-)
> 
> _______________________________________________
> linuxsh-dev mailing list
> lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxsh-dev

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

Re: [linuxsh-dev] Re: [linuxdc-dev][PATCH] maple keyboard fix

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

On Thu, 2001-12-06 at 16:04, Jeremy Siegel wrote:

> Sorry about missing that one.  In the linuxsh drop-in tree, maple_keyb.c
> looks like the only file that references memscan; as far as I can tell the
> only other reference in the entire linux tree is drivers/usb/usbkbd.c, the
> driver that maple_keyb.c was based on.

Heh, nothing to apologize for.  Yah, it seems nothing else in SH uses
memscan.  Good.  drivers/usb/usbkbd does use it, and I bet that is a
bug.  Its in a conditional and since it always evaluates to true ...
whoops!  I think some other places do use it, though.  UDF and ext2, for
example, and it is legitimate.  If not we could rip it out of everything
and save some space.

	Robert Love

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

[Tom R. <tr...@ke...>]

On Thu, Dec 06, 2001 at 11:41:19PM -0500, Robert Love wrote:
> On Thu, 2001-12-06 at 23:19, Tom Rini wrote:
> 
> > Er, having an $(ARCH) tree makes sure that said $(ARCH) actually has a
> > useable tree.  It's always good to try and sync up with
> > Linus/Marcelo/Alan, but you don't want to be sending every diff to them
> > either.  In the ideal world, kernel.org works for the 95% case for
> > $(ARCH) and gets updated from the community tree.
> 
> I completely agree.
> 
> My point was that ideally there would be no syncing at all.  For
> example, SH could be one of many modules in the official linux CVS.  We
> take care of that.  If we touch non-SH code, we hand it to takes care of
> that.

That's sort-of how *BSD works.  We have The One True Tree which everyone
else has a backup of on their harddrive now :)

> > > 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 ...
> > 
> > It depends on just how divergent.  The sparc tree has some very
> > different code from time to time than what Linus does, and it either
> > gets merged or tossed.  Same deal for the PPC _devel tree.  If you put a
> > comment (or a msg or two to a relevant list) people know or can figure
> > it out.
> 
> I think sparc is an exception because its in vger, which can be said to
> be its own kernel tree.

vger is as much of it's own tree as the PPC one.  It's got sparc* and
network stuff (since DaveM is the maintainer of that too).  There's also
the ARM trees and I know m68k has a tree.  My point being that an
$(ARCH) tree is an important thing to have.

> But I really do think PPC is a good example of how to manage a non-x86
> port.  PPC64 maybe not (IBM is heavily involved <grin>), but PPC seems
> pretty well off.

Well, PPC64 isn't in kernel.org either, so lets ignore it for now.

-- 
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

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

[Tom R. <tr...@ke...>]

On Thu, Dec 06, 2001 at 10:35:01PM -0600, M. R. Brown wrote:
> * Tom Rini <tr...@ke...> on Thu, Dec 06, 2001:
> 
> > 
> > Er, having an $(ARCH) tree makes sure that said $(ARCH) actually has a
> > useable tree.  It's always good to try and sync up with
> > Linus/Marcelo/Alan, but you don't want to be sending every diff to them
> > either.  In the ideal world, kernel.org works for the 95% case for
> > $(ARCH) and gets updated from the community tree.
> 
> Call me unorthadox, but, why not?  You see hundreds of small patches on
> lkml daily.  Why can't we be in that flurry as well?

How many of those get picked up?  Alan was pretty good about it, and
hopefully Marcelo will be too.  But also how many of those are for the
same system?

> Who says that arch
> changes must come in one big lump?  According to Linus, they're less likely
> to be accepted if they do come in large sizes.

It all falls under 'Zen and the art of getting your patch to Linus' I
think.  There are no real rule.  I've seen Linus ignore 5 small
incremental patches and then pick them up when someone else resends 'em
as one large patch.  I've also gotten 5 small patches in.  And sometimes
you can't break changes down all that much (at least in unstable/dev
stuff).

> > You can't just 'send off a diff', you need to create it, test it a bit,
> > and hope it doesn't cause any problems.  And then that
> > Linus/Marcelo/Alan doesn't loose it in a flood of other patches/emails.
> 
> Um, couldn't "sending a diff off" be interpreted as the 3 steps you just
> listed? :)

Well yes, but they do entail a bit more than what robert implied anyhow.
It usually takes some twisting of clue-enabled users to test things too.

> > Working in 2.5 is a non-issue for the moment.  2.5 won't work on x86 for 
> > a while. Hell, I imagine it'll take a while before Linus doesn't drop 
> > other arch patches on the floor.
> 
> I think everyone can agree on that.  But we still need to get changes for
> 2.4.x out...

Most definatly.

-- 
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

Re: [linux-sh:02047] Re: [linuxsh-dev] Drop-In tree updates

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

M. R. Brown wrote:
 > Yes, today there is divergence.  But it doesn't have to always be this way.
 > I'm proposing that we become much more agressive in sending patches against
 > mainline to their respective maintainters, and Marcelo and Linus.  We don't
 > have any excuse not to.  If a patch is desperately needed (I can hear Greg
 > and Stuart talking about a PCMCIA patch) and the maintainer of that code
 > remains unresponsive, then send it to Marcelo or Linus CC'd to the
 > maintainer and lkml.  This way everyone gets to see it, and even if it
 > still doesn't go in people can fix it on their own.

I see your point here.  I agree.

 > Not if we stay in sync on a regular basis.  Even still, there's now
 > incremental pre- patches on kernel.org, so syncing from older versions
 > should be much easier.  As far as limited resource, you've just been
 > offered help to do the merging work.  What's wrong with Robert doing a
 > merge and posting it here before it gets sent to Linus?  Being the
 > maintainer, you can easily review and approve/decline the patch as
 > necessary .. do you have any objections to that?

OK, I see your point.  I agree this point.

I've confused that you have objection about the handling of
mm/memory.c and I misunderstood sending #ifdef CONFIG_SUPERH version
to main line were the solution.

Here, we have two issues, specific one for mm/memory.c and general
LinuxSH work.  For latter, thanks for your proposal and others, I
think that it's reasonable.

Note that there is some divergence (though we should minimize it) that
should _not_ be sent to mainline, and should leave local... please
read on.

For mm/memory.c, I think that this divergence is needed (at least for
me), because I do this cache handling work and I think that it is not
good thing to send it to mainline.  So, I ask you or others not to
send it to mainline and not change it as if it's done (CONFIG_SUPERH).
It is intentional.  It is the my local signature, where we should
think about better solution but for a while, work around.  It is no
thank you for me, to do some cosmetic change and then to send it
mainline.  I hope you understand this point.

 > If it only applies to SuperH then it is a CONFIG_SUPERH thing.

No, it's not only SuperH.  The change should go API.  See other API of
cache handling routines.  Same API and different implementation,
instead of having many #ifdef CONFIG_* thing in the code.

We cannot just nullify flush_cache_page, because other usage of
flush_cache_page is valid.  Well, the work is something like this: We
need to distingush the cases, and would define
flush_cache_page_SOMETING and replace the occurrence (currently
#if0-outed) of flush_cache_page in to flush_cache_page_SOMETING.  We
need to check the API change is good and clean for other archtecture.
If it's good for the generic part of kernel and a like...

Please read David Woodhouse's comment.
-- 

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

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

On Thu, 2001-12-06 at 23:19, Tom Rini wrote:

> Er, having an $(ARCH) tree makes sure that said $(ARCH) actually has a
> useable tree.  It's always good to try and sync up with
> Linus/Marcelo/Alan, but you don't want to be sending every diff to them
> either.  In the ideal world, kernel.org works for the 95% case for
> $(ARCH) and gets updated from the community tree.

I completely agree.

My point was that ideally there would be no syncing at all.  For
example, SH could be one of many modules in the official linux CVS.  We
take care of that.  If we touch non-SH code, we hand it to takes care of
that.

> > 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 ...
> 
> It depends on just how divergent.  The sparc tree has some very
> different code from time to time than what Linus does, and it either
> gets merged or tossed.  Same deal for the PPC _devel tree.  If you put a
> comment (or a msg or two to a relevant list) people know or can figure
> it out.

I think sparc is an exception because its in vger, which can be said to
be its own kernel tree.

But I really do think PPC is a good example of how to manage a non-x86
port.  PPC64 maybe not (IBM is heavily involved <grin>), but PPC seems
pretty well off.

> You can't just 'send off a diff', you need to create it, test it a bit,
> and hope it doesn't cause any problems.  And then that
> Linus/Marcelo/Alan doesn't loose it in a flood of other patches/emails.

Agreed.  We have a current CVS, and we know it works.  I rediffed it
against 2.4.17-pre5 and it seems fine.  So the SH part is trivial.  Now,
non-SH stuff is a minimum (I think we touch _one_ non-SH-specific item)
so that is trivial too.

> > Well, CML2 is going in 2.5 in a release or two.  Eric Raymond
> > specifically says SH is out of sync -- and is the only thing out of sync
> > -- at the maintainers request that he do it himself.  We won't work in
> > 2.5 until this is fixed.
> 
> Working in 2.5 is a non-issue for the moment.  2.5 won't work on x86 for 
> a while. Hell, I imagine it'll take a while before Linus doesn't drop 
> other arch patches on the floor.

	Robert Love

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

[M. R. B. <mr...@0x...>]

* Tom Rini <tr...@ke...> on Thu, Dec 06, 2001:

>=20
> Er, having an $(ARCH) tree makes sure that said $(ARCH) actually has a
> useable tree.  It's always good to try and sync up with
> Linus/Marcelo/Alan, but you don't want to be sending every diff to them
> either.  In the ideal world, kernel.org works for the 95% case for
> $(ARCH) and gets updated from the community tree.
>=20

Call me unorthadox, but, why not?  You see hundreds of small patches on
lkml daily.  Why can't we be in that flurry as well?  Who says that arch
changes must come in one big lump?  According to Linus, they're less likely
to be accepted if they do come in large sizes.

>=20
> You can't just 'send off a diff', you need to create it, test it a bit,
> and hope it doesn't cause any problems.  And then that
> Linus/Marcelo/Alan doesn't loose it in a flood of other patches/emails.
>=20

Um, couldn't "sending a diff off" be interpreted as the 3 steps you just
listed? :)

>=20
> Working in 2.5 is a non-issue for the moment.  2.5 won't work on x86 for=
=20
> a while. Hell, I imagine it'll take a while before Linus doesn't drop=20
> other arch patches on the floor.
>=20

I think everyone can agree on that.  But we still need to get changes for
2.4.x out...

M. R.

Re: [linux-sh:02046] Re: [linuxsh-dev] Drop-In tree updates

[Tom R. <tr...@ke...>]

On Thu, Dec 06, 2001 at 11:17:23PM -0500, Robert Love wrote:
> On Thu, 2001-12-06 at 23:11, Tom Rini wrote:
> 
> > I hate to say it, but just because you send things to Linus, doesn't
> > mean they get in.  While it is important to try, it's just as important
> > to have a good public tree that does work on an arch.  If things
> > actually got in for SH around 2.4.13 (I don't remember all of the
> > changes in those pre-patches) SH is actually pretty well off in this
> > regard.  Maybe Marcelo will be better about it, but it'll still take
> > time for everything to settle down..
> 
> Sadly true.  However, I think we could convince him to merge something
> now in 2.5.

I guess see my other email.

> As for 2.4, I already asked Marcelo if he would take a merge.  He will.

Yes, but that doesn't mean it will get in right away either.  Marcelo
has a patch for PPC right now that's waiting a quite enough -pre to drop
in. :)

> > Just my two cents, what's worked well for PPC so far is having a tree
> > that the active and knowledge able people can write to, keeping it close
> > to kernel.org, and frequent patchbombing of Linus.  We've also got a
> > list for commit msgs, and with verbose comments (and followups) everyone
> > usually knows what's going on.
> 
> PPC is very well up-to-date in the official tree, and I think that is a
> good thing.  Good job.

PPC isn't nearly as up to date in kernel.org as you think.  There's a
very large patch right now, to be followed up by a few large (because
lots of files move) patch and then even more small patches for new
boards.  Hopefully 2.4.20 or so will be really really good on PPC and a
few other !x86 arches.

-- 
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

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

[Tom R. <tr...@ke...>]

On Thu, Dec 06, 2001 at 09:44:34PM -0500, Robert Love wrote:
> On Thu, 2001-12-06 at 20:41, NIIBE Yutaka wrote:
> 
> > Ideal stuation would be like that (fully compatible and fully
> > synchronized), but there are some parts which is not, _always_.
> > Sometimes, we have to maintain the differences, say, a year or so to
> > get merged.  It's unwise, well, quite impractical to ignore the
> > existence of diversion.  If it's really being synched, there is no
> > sence to have SH repository, in the first place.
> 
> I disagree.  I think in an ideal world, we would not diverge at all. 
> But we can't honestly expect to develop in sync with Linus and the x86
> arch so we have to work separately.  Having a CVS repository exists to
> make the job easier; nothing else.

Er, having an $(ARCH) tree makes sure that said $(ARCH) actually has a
useable tree.  It's always good to try and sync up with
Linus/Marcelo/Alan, but you don't want to be sending every diff to them
either.  In the ideal world, kernel.org works for the 95% case for
$(ARCH) and gets updated from the community tree.

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

It depends on just how divergent.  The sparc tree has some very
different code from time to time than what Linus does, and it either
gets merged or tossed.  Same deal for the PPC _devel tree.  If you put a
comment (or a msg or two to a relevant list) people know or can figure
it out.

> What sort of problem does someone sending a diff off to Linus and
> Marcelo cause?  It makes our "drop in" tree smaller and our resyncing
> easy.

You can't just 'send off a diff', you need to create it, test it a bit,
and hope it doesn't cause any problems.  And then that
Linus/Marcelo/Alan doesn't loose it in a flood of other patches/emails.

> Well, CML2 is going in 2.5 in a release or two.  Eric Raymond
> specifically says SH is out of sync -- and is the only thing out of sync
> -- at the maintainers request that he do it himself.  We won't work in
> 2.5 until this is fixed.

Working in 2.5 is a non-issue for the moment.  2.5 won't work on x86 for 
a while. Hell, I imagine it'll take a while before Linus doesn't drop 
other arch patches on the floor.

-- 
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

Re: [linux-sh:02046] Re: [linuxsh-dev] Drop-In tree updates

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

On Thu, 2001-12-06 at 23:11, Tom Rini wrote:

> I hate to say it, but just because you send things to Linus, doesn't
> mean they get in.  While it is important to try, it's just as important
> to have a good public tree that does work on an arch.  If things
> actually got in for SH around 2.4.13 (I don't remember all of the
> changes in those pre-patches) SH is actually pretty well off in this
> regard.  Maybe Marcelo will be better about it, but it'll still take
> time for everything to settle down..

Sadly true.  However, I think we could convince him to merge something
now in 2.5.

As for 2.4, I already asked Marcelo if he would take a merge.  He will.

> Just my two cents, what's worked well for PPC so far is having a tree
> that the active and knowledge able people can write to, keeping it close
> to kernel.org, and frequent patchbombing of Linus.  We've also got a
> list for commit msgs, and with verbose comments (and followups) everyone
> usually knows what's going on.

PPC is very well up-to-date in the official tree, and I think that is a
good thing.  Good job.

	Robert Love

Re: [linux-sh:02047] Re: [linuxsh-dev] Drop-In tree updates

[M. R. B. <mr...@0x...>]

* NIIBE Yutaka <gn...@m1...> on Fri, Dec 07, 2001:

>=20
> I don't say, we should encourage incompatibility or divergent tree.  I
> said, we have to think about maintaining the divergence.  Although we
> should do our best to minimize the divergence, there _is_ always
> divergence and it is quite important to maintain the divergence and
> merging.
>=20

Yes, today there is divergence.  But it doesn't have to always be this way.
I'm proposing that we become much more agressive in sending patches against
mainline to their respective maintainters, and Marcelo and Linus.  We don't
have any excuse not to.  If a patch is desperately needed (I can hear Greg
and Stuart talking about a PCMCIA patch) and the maintainer of that code
remains unresponsive, then send it to Marcelo or Linus CC'd to the
maintainer and lkml.  This way everyone gets to see it, and even if it
still doesn't go in people can fix it on their own.

We have to up the ante, we shouldn't just blindly accept breakage from up
high.

> It takes time to do the merging, and since the band width (of human
> being) is limited resource, we should be careful to do the merging.
>=20

Not if we stay in sync on a regular basis.  Even still, there's now
incremental pre- patches on kernel.org, so syncing from older versions
should be much easier.  As far as limited resource, you've just been
offered help to do the merging work.  What's wrong with Robert doing a
merge and posting it here before it gets sent to Linus?  Being the
maintainer, you can easily review and approve/decline the patch as
necessary .. do you have any objections to that?

>=20
> Yes.  You did good job towards this goal.  Don't you think that part
> of mm/memory.c is maintained by me?
>=20
[...]
> Because I maintain this divergence of mm/memory.c.  Obviously, it's
> ugly hack, but it's important for performance wise for SuperH or other
> relevant architecture.  We need API change for cache handling routines
> for merge, but for a while it's good.  It's definitely _not_
> CONFIG_SUPERH thing.  For me, it looks quite selfish and bad code for
> generic part of kernel to have CONFIG_SUPERH if it's not really
> needed.
>=20

If it only applies to SuperH then it is a CONFIG_SUPERH thing.  CONFIG_*
options are specific to what they define, if they weren't, would we have
CONFIG_SH_DREAMCAST sprinkled all over drivers/net/8139too.c ?

If something needs to be changed in mainline for our port to work, then we
need to change it, just as you've been sending patches to fix gcc, this is
the same idea.

>=20
> It's good tools.  But unfortunately, it's not perfect.  If some part
> is not going in, then, he has divergence in his working tree, isn't
> it?
>=20

Yes, for awhile.  I'm saying we should cut that time short, and *not* have
stale code that could've went into mainline (or been fixed) sitting around
for a year or so.

>=20
> I have been doing that.  I don't think other person sending patches
> help things here.  Say, do you believe RedHat users who find
> divergence between mainline and the kernel distributed by RedHat
> sending the difference to Linus?  I don't think so.
>=20

We're not just users, we're developers.  Red Hat users don't submit kernel
patches to Red Hat, Red Hat has it's own kernel development team that
maintains its patches, just as you and I and Paul and Jeremy maintain parts
of the LinuxSH tree.  So your analogy doesn't hold here.  And yeah, if
someone has a problem in our area of code, then we should be the ones to
respond, just like Red Hat is responsible for tracking support for it's
code.

Oh, and you haven't been regularly sending patches to Linus, else we
wouldn't be having this discussion!

>=20
> For me, 2.5 thing is better to follow.  2.4 is difficult.

I don't want to go back and forth (and I'm sure you don't), so I'll just
say this - help is being offered to ease your workload.  The communication
lines are open, and you have some experienced kernel hackers that are
willing to give you assistance.  If the situation occurs where it takes too
long for changes to be accepted and/or passed back to Linus, then you'll
eventually end up with the same sort of "fork" that happened with SGI OSS
and linux-mips.  Ask those developers why they chose to open another tree.

M. R.

Re: [linux-sh:02046] Re: [linuxsh-dev] Drop-In tree updates

[Tom R. <tr...@ke...>]

On Thu, Dec 06, 2001 at 08:22:38PM -0600, M. R. Brown wrote:
> > It is me, because I am a maintainer.  It was late 2.4.13.  Since that
> > time, because of the priority of GCC synchronization, I have been
> > spent most of time to have GCC patches to gather, send to upstream,
> > evaluate, generate local patches, etc. 
> 
> 
> I understand you've been busy with other tasks.  But it's time that the SH
> tree catches up with the real world, and it's difficult to do that if we
> aren't regularly syncing back to Linus.

I hate to say it, but just because you send things to Linus, doesn't
mean they get in.  While it is important to try, it's just as important
to have a good public tree that does work on an arch.  If things
actually got in for SH around 2.4.13 (I don't remember all of the
changes in those pre-patches) SH is actually pretty well off in this
regard.  Maybe Marcelo will be better about it, but it'll still take
time for everything to settle down..

> IMO, we need to become much more organized for the 2.5 line of development.
> What I mean by organization is that we need to know when to send patches to
> mainline, notify each other what breaks and why and who's responsible for
> what areas of code.  I'm currently the Dreamcast maintainer, but I have
> some non-DC code I'd like to submit which I would of course maintain if it
> got in.

Just my two cents, what's worked well for PPC so far is having a tree
that the active and knowledge able people can write to, keeping it close
to kernel.org, and frequent patchbombing of Linus.  We've also got a
list for commit msgs, and with verbose comments (and followups) everyone
usually knows what's going on.

-- 
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

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

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

I don't propose the fork.  I say, there's always things to merge.

M. R. Brown wrote:
 > I can't buy that.

Yes, I know.  We have different view.

 > What's the purpose of purposely maintaining
 > a divergent tree, if doing so increases workload and has the potential to
 > break things on our end?  We should be much more active in fixing mainline
 > as well as our port, see the post the last couple of days about removing
 > segment.h from all source files (we needed that), etc.  We shouldn't be
 > isolationists, and encourage incompatibility.

I don't say, we should encourage incompatibility or divergent tree.  I
said, we have to think about maintaining the divergence.  Although we
should do our best to minimize the divergence, there _is_ always
divergence and it is quite important to maintain the divergence and
merging.

It takes time to do the merging, and since the band width (of human
being) is limited resource, we should be careful to do the merging.

 > IMHO, we have an SH repository so that each maintainer can work on her
 > own areas of code in a semi-controlled fasion.

Yes.  You did good job towards this goal.  Don't you think that part
of mm/memory.c is maintained by me?

 > > And it has been _me_ (and I think still _is_) who work for the
 > > synchronization.  And I ask you and others to leave it as #if 0,
 > > because it is good for me to do the synchronization work.
 > >=20
 > 
 > Why?

Because I maintain this divergence of mm/memory.c.  Obviously, it's
ugly hack, but it's important for performance wise for SuperH or other
relevant architecture.  We need API change for cache handling routines
for merge, but for a while it's good.  It's definitely _not_
CONFIG_SUPERH thing.  For me, it looks quite selfish and bad code for
generic part of kernel to have CONFIG_SUPERH if it's not really
needed.

 > No, that's what peer patch review is for.  Everyone can see what patches
 > are proposed and object to them before they go in.  Nothing is being
 > hidden.

It's good tools.  But unfortunately, it's not perfect.  If some part
is not going in, then, he has divergence in his working tree, isn't
it?

 > I understand you've been busy with other tasks.  But it's time that the SH
 > tree catches up with the real world, and it's difficult to do that if we
 > aren't regularly syncing back to Linus.

I have been doing that.  I don't think other person sending patches
help things here.  Say, do you believe RedHat users who find
divergence between mainline and the kernel distributed by RedHat
sending the difference to Linus?  I don't think so.

 > How about this?  Would you have a problem remaining the 2.4 maintainer,
 > while someone else stepped up to become the 2.5 maintainer?

For me, 2.5 thing is better to follow.  2.4 is difficult.
-- 

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

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

On Thu, 2001-12-06 at 20:41, NIIBE Yutaka wrote:

> Sorry, I don't share your view.  No, I don't say you're wrong.  I
> think that it's a sort of matter of taste or discipline (work style).

Sorry, but I can't see any rational reason for putting an if 0 in code
such that it disables perfectly working code under other arches.

If you have a superior solution, go for it.

Regardless, you are the maintainer and I respect that.  Your call.

> Ideal stuation would be like that (fully compatible and fully
> synchronized), but there are some parts which is not, _always_.
> Sometimes, we have to maintain the differences, say, a year or so to
> get merged.  It's unwise, well, quite impractical to ignore the
> existence of diversion.  If it's really being synched, there is no
> sence to have SH repository, in the first place.

I disagree.  I think in an ideal world, we would not diverge at all. 
But we can't honestly expect to develop in sync with Linus and the x86
arch so we have to work separately.  Having a CVS repository exists to
make the job easier; nothing else.

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

What sort of problem does someone sending a diff off to Linus and
Marcelo cause?  It makes our "drop in" tree smaller and our resyncing
easy.

> And it has been _me_ (and I think still _is_) who work for the
> synchronization.  And I ask you and others to leave it as #if 0,
> because it is good for me to do the synchronization work.

Well, I am here offering to help you -- but again, its you call.

> Having SH repository, people only commit to the repository, not try to
> send the patch to main line.  That's quite bad thing, because it may
> result more diversion and bad quality.  I had spent much time for the
> work of synchronization, and my experience says "don't hide the issue
> if there is work remained for merge".

What do you mean by this?

> If you really want (looks like) sane version, you can have your own
> version.

No, I don't intend to ever divert anything from your control.  A fork is
not going to get us anywhere here.  I just want to _help you_.

> Yes, it depends who does that.
> 
>  > Which brings me to the next point ... the trees are way out of sync. 
> 
> I agree I have things to be done.

Completely understandable.

>  > When was the last time someone pushed an SH merge off to the official
>  > kernel?
> 
> It is me, because I am a maintainer.  It was late 2.4.13.  Since that
> time, because of the priority of GCC synchronization, I have been
> spent most of time to have GCC patches to gather, send to upstream,
> evaluate, generate local patches, etc. 

Understandable; your gcc work is _very_ appreciated.

>  > I would be happy to put together a diff against the latest 2.4 and 2.5
>  > and send it off to Marcelo and Linus for merging into their tree.  I
>  > suspect it will take some work to make sure we keep the code correct
>  > (ie, nothing like the #if 0 stuff).  I would want the maintainer's
>  > permission before I do this.
> 
> Thanks for offering help, but no thank you for this work.  It
> complicate things in a bad way, if I can't see how things are going.
> 
> It is, say, "serialization".  In many cases, this style works well,
> although sometimes it's the bottle neck.  To avoid confusion of
> diversion, it is known to best to serialize merge of the work.

I made a patch of SH drop-in (and my pending patches) vs 2.4.17-pre5. 
The non-SH stuff is trivial.  In other words, not much syncing needs to
be done on our side.  It is their side that needs to catch up to us.  Of
course, what did need to be done would be posted to this list for all to
see.

>  > Second, with 2.5 starting, we need conversion to both CML2 and
>  > kbuild-2.5.
> 
> Yes.  I think that I notified people some time last year, and Greg
> also mentioned last month.
> 
>  > Both are non-trivial changes.  The SH port is the _only_
>  > piece of the kernel non-synced with CML2, supposedly at the maintainer's
>  > request that he do it?
> 
> No.  I don't request.  It's simple, I asked, but none does that.

Well, CML2 is going in 2.5 in a release or two.  Eric Raymond
specifically says SH is out of sync -- and is the only thing out of sync
-- at the maintainers request that he do it himself.  We won't work in
2.5 until this is fixed.

>  > Also, SH items in Configure.help are very lacking.  CML2 will _not_
>  > allow an item to be selected if in non-expert mode if it has no
>  > configure help!  And kbuild-2.5 will require a rewrite of our
>  > makefiles...
> 
> Why don't you contribute this part?  I think that there's no objection
> for 2.5 tree to do that job.  If you don't have write access to the
> repository, please ask.

	Robert Love

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

[M. R. B. <mr...@0x...>]

* NIIBE Yutaka <gn...@m1...> on Fri, Dec 07, 2001:

>=20
> Ideal stuation would be like that (fully compatible and fully
> synchronized), but there are some parts which is not, _always_.
> Sometimes, we have to maintain the differences, say, a year or so to
> get merged.  It's unwise, well, quite impractical to ignore the
> existence of diversion.  If it's really being synched, there is no
> sence to have SH repository, in the first place.
>=20

I can't buy that.  Aren't one of the LinuxSH goals to make the SH arch
backend available to everyone?  What's the purpose of purposely maintaining
a divergent tree, if doing so increases workload and has the potential to
break things on our end?  We should be much more active in fixing mainline
as well as our port, see the post the last couple of days about removing
segment.h from all source files (we needed that), etc.  We shouldn't be
isolationists, and encourage incompatibility.  Especially when huge (and
not so huge) companies have an invested interest in what we produce.

IMHO, we have an SH repository so that each maintainer can work on her
own areas of code in a semi-controlled fasion.  Not so that we can just be
"different".

> And it has been _me_ (and I think still _is_) who work for the
> synchronization.  And I ask you and others to leave it as #if 0,
> because it is good for me to do the synchronization work.
>=20

Why?

> Having SH repository, people only commit to the repository, not try to
> send the patch to main line.  That's quite bad thing, because it may
> result more diversion and bad quality.  I had spent much time for the
> work of synchronization, and my experience says "don't hide the issue
> if there is work remained for merge".
>=20

No, that's what peer patch review is for.  Everyone can see what patches
are proposed and object to them before they go in.  Nothing is being
hidden.

> If you really want (looks like) sane version, you can have your own
> version.
>=20

Are you proposing a fork?

> Yes, it depends who does that.
>=20
[...]
>=20
> I agree I have things to be done.
>=20

I can understand you having limited time to work on things, I've often
delayed submissions for months because I didn't have the time to finish
them.  But that's the benefit of our style of development, anyone else
who's willing can step up and help you out.  Why refuse that help?

>=20
> It is me, because I am a maintainer.  It was late 2.4.13.  Since that
> time, because of the priority of GCC synchronization, I have been
> spent most of time to have GCC patches to gather, send to upstream,
> evaluate, generate local patches, etc.=20
>=20

I understand you've been busy with other tasks.  But it's time that the SH
tree catches up with the real world, and it's difficult to do that if we
aren't regularly syncing back to Linus.

How about this?  Would you have a problem remaining the 2.4 maintainer,
while someone else stepped up to become the 2.5 maintainer?  Since we're
talking about divergance anyway, the linux-2_4-branch and HEAD will soon
become (think directory restructuring) as divergent as the gcc 3.0 branch
and gcc HEAD.  It's going to be a ton of more work than what exists for the
2.4 series today.

Is there anyone else who'd even want the maintainers chair?

>=20
> Thanks for offering help, but no thank you for this work.  It
> complicate things in a bad way, if I can't see how things are going.
>=20

That's why we're all on this mailing list.  We already submit to patch
review ... how can you not see how things are going?

IMO, we need to become much more organized for the 2.5 line of development.
What I mean by organization is that we need to know when to send patches to
mainline, notify each other what breaks and why and who's responsible for
what areas of code.  I'm currently the Dreamcast maintainer, but I have
some non-DC code I'd like to submit which I would of course maintain if it
got in.

M. R.

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

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

Robert Love wrote:
 > Exactly.  That is one reason.  Another is that the #if 0 makes the tree
 > instantly incompatible with any arch other than SH.  The SH tree should
 > be fully compatible with all arches, so that we can resync with each
 > other.

Sorry, I don't share your view.  No, I don't say you're wrong.  I
think that it's a sort of matter of taste or discipline (work style).

Ideal stuation would be like that (fully compatible and fully
synchronized), but there are some parts which is not, _always_.
Sometimes, we have to maintain the differences, say, a year or so to
get merged.  It's unwise, well, quite impractical to ignore the
existence of diversion.  If it's really being synched, there is no
sence to have SH repository, in the first place.

And it has been _me_ (and I think still _is_) who work for the
synchronization.  And I ask you and others to leave it as #if 0,
because it is good for me to do the synchronization work.

Having SH repository, people only commit to the repository, not try to
send the patch to main line.  That's quite bad thing, because it may
result more diversion and bad quality.  I had spent much time for the
work of synchronization, and my experience says "don't hide the issue
if there is work remained for merge".

If you really want (looks like) sane version, you can have your own
version.

Yes, it depends who does that.

 > Which brings me to the next point ... the trees are way out of sync. 

I agree I have things to be done.

 > When was the last time someone pushed an SH merge off to the official
 > kernel?

It is me, because I am a maintainer.  It was late 2.4.13.  Since that
time, because of the priority of GCC synchronization, I have been
spent most of time to have GCC patches to gather, send to upstream,
evaluate, generate local patches, etc. 

 > I would be happy to put together a diff against the latest 2.4 and 2.5
 > and send it off to Marcelo and Linus for merging into their tree.  I
 > suspect it will take some work to make sure we keep the code correct
 > (ie, nothing like the #if 0 stuff).  I would want the maintainer's
 > permission before I do this.

Thanks for offering help, but no thank you for this work.  It
complicate things in a bad way, if I can't see how things are going.

It is, say, "serialization".  In many cases, this style works well,
although sometimes it's the bottle neck.  To avoid confusion of
diversion, it is known to best to serialize merge of the work.

 > Second, with 2.5 starting, we need conversion to both CML2 and
 > kbuild-2.5.

Yes.  I think that I notified people some time last year, and Greg
also mentioned last month.

 > Both are non-trivial changes.  The SH port is the _only_
 > piece of the kernel non-synced with CML2, supposedly at the maintainer's
 > request that he do it?

No.  I don't request.  It's simple, I asked, but none does that.

 > Also, SH items in Configure.help are very lacking.  CML2 will _not_
 > allow an item to be selected if in non-expert mode if it has no
 > configure help!  And kbuild-2.5 will require a rewrite of our
 > makefiles...

Why don't you contribute this part?  I think that there's no objection
for 2.5 tree to do that job.  If you don't have write access to the
repository, please ask.
-- 

[linuxsh-dev] Re: Slow 32 bytes long "mov" delta - Hitachi SH4(7750), SolutionEngine(MS7750SE01E)

[kaz K. <kk...@rr...>]

Hi,

Vladimir Doukhanine <vdo...@wa...> wrote:
> If I copy data from one place to another after each megabyte (delta
> between src and dst)
> there is some kind of "black hole" 32 bytes long in which processor
> works 15 times
> slower.

Which version of kernel are you testing?

	kaz
--
BTW, I've replied to your mail and it returned with Host unknown
error (Name server: wann.com: no data known). It seems the problem
of my ISP. Anyway, please write to the mailing list, not to me :-)

[linuxsh-dev] Slow 32 bytes long "mov" delta - Hitachi SH4(7750), SolutionEngine(MS7750SE01E)

[Vladimir D. <vdo...@wa...>]

Hi,

Can anyone tell me what is going on with a performance.
Isn't it the processor issue?

If I copy data from one place to another after each megabyte (delta
between src and dst)
there is some kind of "black hole" 32 bytes long in which processor
works 15 times
slower.
It happens after 1M, 2M, 3M,  have not tested more.


0..................1M|32bytes.............2M|32bytes.............3M|32bytes             
|--------------------|xxx-------------------|xxx-------------------|xxx


N = 1.2.3
Delta between src and dst     0M     <= DELTA <   1M      -fast
Delta between src and dst   1M*N     <= DELTA <=  1M*N+31 -15 times
slower
Delta between src and dst   1M*N+31  <  DELTA <   1M*N    -fast

It doesn't matter is memory area PAGE_SIZE aligned and not.
I even tested with mmap'ed physical memory allocated at boot time with
"alloc_bootmem_pages" to be sure that it is continuous and not-swappable
- the same result ...

Here is a simplified demo code, output, and disassembly.

Thanks,
Vova



Output:
u8copy1mm1 3145728 chars = 0.174000 sec.
u8copy1m 3145728 chars = 2.392500 sec.
u8copy1mp31 3145728 chars = 2.391000 sec.
u8copy1mp32 3145728 chars = 0.174000 sec.

Code:
//1024*1024*3
#define THREEMEG 3145728
//1M
#define ONEMEGMINUS1 1048575
#define ONEMEG 1048576
#define ONEMEGPLUS31 1048607
#define ONEMEGPLUS32 1048608

void u8copy1mm1(void)
{
 for(ii = 0; ii < THREEMEG; ii++)
  mem8_1[0]=mem8_1[ONEMEGMINUS1];
}
void u8copy1m(void)
{
 for(ii = 0; ii < THREEMEG; ii++)
  mem8_1[0]=mem8_1[ONEMEG];
}
void u8copy1mp31(void)
{
 for(ii = 0; ii < THREEMEG; ii++)
  mem8_1[0]=mem8_1[ONEMEGPLUS31];
}
void u8copy1mp32(void)
{
 for(ii = 0; ii < THREEMEG; ii++)
  mem8_1[0]=mem8_1[ONEMEGPLUS32];
}

  start = clock();
  for( k = 0; k < NUMBEROFLOOPS; k++ )
   u8copy1mm1();
  end = clock();
  cpu_time_used = (((double)(end-start))/CLOCKS_PER_SEC)/k;
  printf("u8copy1mm1 %i chars = %f sec.\n",THREEMEG,cpu_time_used);

  start = clock();
  for( k = 0; k < NUMBEROFLOOPS; k++ )
   u8copy1m();
  end = clock();
  cpu_time_used = (((double)(end-start))/CLOCKS_PER_SEC)/k;
  printf("u8copy1m %i chars = %f sec.\n",THREEMEG,cpu_time_used);

  start = clock();
  for( k = 0; k < NUMBEROFLOOPS; k++ )
   u8copy1mp31();
  end = clock();
  cpu_time_used = (((double)(end-start))/CLOCKS_PER_SEC)/k;
  printf("u8copy1mp31 %i chars = %f sec.\n",THREEMEG,cpu_time_used);

  start = clock();
  for( k = 0; k < NUMBEROFLOOPS; k++ )
   u8copy1mp32();
  end = clock();
  cpu_time_used = (((double)(end-start))/CLOCKS_PER_SEC)/k;
  printf("u8copy1mp32 %i chars = %f sec.\n",THREEMEG,cpu_time_used);


Output:

 mem1 = 0x29711000
THREEMEG = 3145728 NUMBEROFLOOPS = 10
u8copy1mm1 3145728 chars = 0.174000 sec.
u8copy1m 3145728 chars = 2.392500 sec.
u8copy1mp31 3145728 chars = 2.391000 sec.
u8copy1mp32 3145728 chars = 0.174000 sec.


Disassembly:

00402240 <u8copy1mm1>:
  402240:       09 d2           mov.l  
402268<u8copy1mm1+0x28>,r2!0x413940
  402242:       00 e1           mov     #0,r1
  402244:       09 d6           mov.l  
40226c<u8copy1mm1+0x2c>,r6!0x2fffff
  402246:       0a d7           mov.l  
402270<u8copy1mm1+0x30>,r7!0x413900
  402248:       23 63           mov     r2,r3
  40224a:       0a d0           mov.l  
402274<u8copy1mm1+0x34>,r0!0xfffff
  40224c:       e6 2f           mov.l   r14,@-r15
  40224e:       12 22           mov.l   r1,@r2
  402250:       f3 6e           mov     r15,r14
  402252:       72 62           mov.l   @r7,r2
  402254:       2c 04           mov.b   @(r0,r2),r4
  402256:       40 22           mov.b   r4,@r2
  402258:       32 61           mov.l   @r3,r1
  40225a:       01 71           add     #1,r1
  40225c:       67 31           cmp/gt  r6,r1
  40225e:       f8 8f           bf.s    402252 <u8copy1mm1+0x12>
  402260:       12 23           mov.l   r1,@r3
  402262:       e3 6f           mov     r14,r15
  402264:       0b 00           rts
  402266:       f6 6e           mov.l   @r15+,r14
  402268:       40 39           cmp/eq  r4,r9
  40226a:       41 00           .word 0x0041
  40226c:       ff ff           .word 0xffff
  40226e:       2f 00           mac.l   @r2+,@r0+
  402270:       00 39           cmp/eq  r0,r9
  402272:       41 00           .word 0x0041
  402274:       ff ff           .word 0xffff
  402276:       0f 00           mac.l   @r0+,@r0+
  402278:       09 00           nop
  40227a:       09 00           nop
  40227c:       09 00           nop
  40227e:       09 00           nop


00402280 <u8copy1m>:
  402280:       09 d2           mov.l  
4022a8<u8copy1m+0x28>,r2!0x413940
  402282:       00 e1           mov     #0,r1
  402284:       09 d6           mov.l  
4022ac<u8copy1m+0x2c>,r6!0x2fffff
  402286:       0a d7           mov.l  
4022b0<u8copy1m+0x30>,r7!0x413900
  402288:       23 63           mov     r2,r3
  40228a:       0a d0           mov.l  
4022b4<u8copy1m+0x34>,r0!0x100000
  40228c:       e6 2f           mov.l   r14,@-r15
  40228e:       12 22           mov.l   r1,@r2
  402290:       f3 6e           mov     r15,r14
  402292:       72 62           mov.l   @r7,r2
  402294:       2c 04           mov.b   @(r0,r2),r4
  402296:       40 22           mov.b   r4,@r2
  402298:       32 61           mov.l   @r3,r1
  40229a:       01 71           add     #1,r1
  40229c:       67 31           cmp/gt  r6,r1
  40229e:       f8 8f           bf.s    402292 <u8copy1m+0x12>
  4022a0:       12 23           mov.l   r1,@r3
  4022a2:       e3 6f           mov     r14,r15
  4022a4:       0b 00           rts
  4022a6:       f6 6e           mov.l   @r15+,r14
  4022a8:       40 39           cmp/eq  r4,r9
  4022aa:       41 00           .word 0x0041
  4022ac:       ff ff           .word 0xffff
  4022ae:       2f 00           mac.l   @r2+,@r0+
  4022b0:       00 39           cmp/eq  r0,r9
  4022b2:       41 00           .word 0x0041
  4022b4:       00 00           .word 0x0000
  4022b6:       10 00           .word 0x0010
  4022b8:       09 00           nop
  4022ba:       09 00           nop
  4022bc:       09 00           nop
  4022be:       09 00           nop


004022c0 <u8copy1mp31>:
  4022c0:       09 d2           mov.l  
4022e8<u8copy1mp31+0x28>,r2!0x413940
  4022c2:       00 e1           mov     #0,r1
  4022c4:       09 d6           mov.l  
4022ec<u8copy1mp31+0x2c>,r6!0x2fffff
  4022c6:       0a d7           mov.l  
4022f0<u8copy1mp31+0x30>,r7!0x413900
  4022c8:       23 63           mov     r2,r3
  4022ca:       0a d0           mov.l  
4022f4<u8copy1mp31+0x34>,r0!0x10001f
  4022cc:       e6 2f           mov.l   r14,@-r15
  4022ce:       12 22           mov.l   r1,@r2
  4022d0:       f3 6e           mov     r15,r14
  4022d2:       72 62           mov.l   @r7,r2
  4022d4:       2c 04           mov.b   @(r0,r2),r4
  4022d6:       40 22           mov.b   r4,@r2
  4022d8:       32 61           mov.l   @r3,r1
  4022da:       01 71           add     #1,r1
  4022dc:       67 31           cmp/gt  r6,r1
  4022de:       f8 8f           bf.s    4022d2 <u8copy1mp31+0x12>
  4022e0:       12 23           mov.l   r1,@r3
  4022e2:       e3 6f           mov     r14,r15
  4022e4:       0b 00           rts
  4022e6:       f6 6e           mov.l   @r15+,r14
  4022e8:       40 39           cmp/eq  r4,r9
  4022ea:       41 00           .word 0x0041
  4022ec:       ff ff           .word 0xffff
  4022ee:       2f 00           mac.l   @r2+,@r0+
  4022f0:       00 39           cmp/eq  r0,r9
  4022f2:       41 00           .word 0x0041
  4022f4:       1f 00           mac.l   @r1+,@r0+
  4022f6:       10 00           .word 0x0010
  4022f8:       09 00           nop
  4022fa:       09 00           nop
  4022fc:       09 00           nop
  4022fe:       09 00           nop


00402300 <u8copy1mp32>:
  402300:       09 d2           mov.l  
402328<u8copy1mp32+0x28>,r2!0x413940
  402302:       00 e1           mov     #0,r1
  402304:       09 d6           mov.l  
40232c<u8copy1mp32+0x2c>,r6!0x2fffff
  402306:       0a d7           mov.l  
402330<u8copy1mp32+0x30>,r7!0x413900
  402308:       23 63           mov     r2,r3
  40230a:       0a d0           mov.l  
402334<u8copy1mp32+0x34>,r0!0x100020
  40230c:       e6 2f           mov.l   r14,@-r15
  40230e:       12 22           mov.l   r1,@r2
  402310:       f3 6e           mov     r15,r14
  402312:       72 62           mov.l   @r7,r2
  402314:       2c 04           mov.b   @(r0,r2),r4
  402316:       40 22           mov.b   r4,@r2
  402318:       32 61           mov.l   @r3,r1
  40231a:       01 71           add     #1,r1
  40231c:       67 31           cmp/gt  r6,r1
  40231e:       f8 8f           bf.s    402312 <u8copy1mp32+0x12>
  402320:       12 23           mov.l   r1,@r3
  402322:       e3 6f           mov     r14,r15
  402324:       0b 00           rts
  402326:       f6 6e           mov.l   @r15+,r14
  402328:       40 39           cmp/eq  r4,r9
  40232a:       41 00           .word 0x0041
  40232c:       ff ff           .word 0xffff
  40232e:       2f 00           mac.l   @r2+,@r0+
  402330:       00 39           cmp/eq  r0,r9
  402332:       41 00           .word 0x0041
  402334:       20 00           .word 0x0020
  402336:       10 00           .word 0x0010
  402338:       09 00           nop
  40233a:       09 00           nop
  40233c:       09 00           nop
  40233e:       09 00           nop

Re: [linuxsh-dev] Re: [linuxdc-dev][PATCH] maple keyboard fix

[Jeremy S. <js...@mv...>]

Robert Love wrote:

> Thank you.  As SH users start using 2.4.15-pre7 and later kernels, they
> may experience odd problems.  I wish I could give a formula for tracking
> down if a specific issue is this memchr/memscan problem, but it can
> manifest itself in a myriad of ways.
>
> One thing to consider is that _all_ uses of memscan are either broken
> now or where broken before the change.  I.e., they expected one of the
> two behaviors at some point but got the other.  This means a global
> audit of memscan use may be useful.

Sorry about missing that one.  In the linuxsh drop-in tree, maple_keyb.c
looks like the only file that references memscan; as far as I can tell the
only other reference in the entire linux tree is drivers/usb/usbkbd.c, the
driver that maple_keyb.c was based on.

--Jeremy Siegel

Re: [linuxsh-dev] Re: [PATCH] Preemptible kernel for SH

[Kimball M. <km...@ti...>]

Robert Love wrote:
> 
> Users of gcc-3.x will need the attached patch _for gcc_ to compile an SH
> kernel patched with preempt-kernel.  This is _not_ our fault, it is a
> gcc bug and is now merged into CVS and should be part of gcc-3.1.
> 
> gcc-2.9x compiles without problem.  It is only 3.x versions that suffer
> the bug.
> 
>         Robert Love
> 
> P.S. Also of note: yes this works on Sega Dreamcast.  You can have a
> fully preemptible Dreamcast.  Impress your friends.  Or something.
> 
>   ------------------------------------------------------------------------
>                                 Name: gcc-ice-rml-3.0.2-1.patch
>    gcc-ice-rml-3.0.2-1.patch    Type: Plain Text (text/plain)
>                             Encoding: quoted-printable

Hi all!  

	My name is Kimball Murray and I have just recently completed a fully
preemptible kernel port for TimeSys Corporation that runs on the SH3/SH4
boards.
This kernel also runs all IRQ handlers as threads (except for the timer
interrupt).
This allows interrupt handlers to be scheduled using priorities (great
for real-
time systems).  The degree of preemption is finer grained than that of
the existing 
preemption patch which should lead to lower latency.

	Additionally, the tool chain and reasonably large root filesystem are
nicely
packaged with a nice install process.  I would be delighted if someone
were to download
the GPL'ed kernel for SH3 or SH4 from www.timesys.com and give it a
whirl. 
We'd love some feedback on this.

	I'd also like to thank the many people whose names pop up so frequently
on this
list who've contributed in countless ways to Linux on the SH processor. 
And special
thanks to the tool chain contributors!

Cheers!

	-Kimball

Re: [linuxsh-dev] Re: [linuxdc-dev][PATCH] maple keyboard fix

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

On Thu, 2001-12-06 at 10:25, M. R. Brown wrote:

> > The attached patch fixes the problems.  There may be more.  _Please_
> > merge into CVS.
> 
> Applied to branch and head - thanks!

Thank you.  As SH users start using 2.4.15-pre7 and later kernels, they
may experience odd problems.  I wish I could give a formula for tracking
down if a specific issue is this memchr/memscan problem, but it can
manifest itself in a myriad of ways.

One thing to consider is that _all_ uses of memscan are either broken
now or where broken before the change.  I.e., they expected one of the
two behaviors at some point but got the other.  This means a global
audit of memscan use may be useful.

	Robert Love

[linuxsh-dev] Re: [linuxdc-dev][PATCH] maple keyboard fix

[M. R. B. <mr...@0x...>]

* Robert Love <rm...@te...> on Thu, Dec 06, 2001:

>=20
> The attached patch fixes the problems.  There may be more.  _Please_
> merge into CVS.

Applied to branch and head - thanks!

M. R.

> --- linux/drivers/char/maple_keyb.c.orig	Thu Dec  6 01:39:45 2001
> +++ linux/drivers/char/maple_keyb.c	Thu Dec  6 01:40:48 2001
> @@ -55,7 +55,7 @@
> =20
>  	for(i=3D2; i<8; i++) {
> =20
> -		if(kbd->old[i]>3&&memscan(kbd->new+2, kbd->old[i], 6)=3D=3DNULL) {
> +		if(kbd->old[i]>3&&memchr(kbd->new+2, kbd->old[i], 6)=3D=3DNULL) {
>  			if(dc_kbd_keycode[kbd->old[i]])
>  				input_report_key(dev,
>  						 dc_kbd_keycode[kbd->old[i]],
> @@ -65,7 +65,7 @@
>  				       kbd->old[i]);
>  		}
> =20
> -		if(kbd->new[i]>3&&memscan(kbd->old+2, kbd->new[i], 6)!=3DNULL) {
> +		if(kbd->new[i]>3&&memchr(kbd->old+2, kbd->new[i], 6)!=3DNULL) {
>  			if(dc_kbd_keycode[kbd->new[i]])
>  				input_report_key(dev,
>  						 dc_kbd_keycode[kbd->new[i]],

[linuxsh-dev] [PATCH] maple keyboard fix

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

In 2.4.15-pre7, the following change to include/asm-sh/string.h were
merged:

-#define __HAVE_ARCH_MEMSCAN
-#define memscan memchr

This was a Good Thing, since the two function are not specified to have
the same behavior.  memchr returns NULL on no match, and memscan returns
addr+1 if a match is not found.

The problem lies in that there is SH arch code that depended on the
false behavior of memscan -- that is, even though they called memscan,
they assumed it returned NULL on no match (since it was defined as
memchr which does just that).

At least one problem area was found: maple_keyb.c, and this was causing
my previously reported keyboard problem on my Dreamcast.

The attached patch fixes the problems.  There may be more.  _Please_
merge into CVS.

	Robert Love