linuxsh-dev

[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

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

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

On Wed, Dec 05, 2001 at 03:06:34PM -0500, Robert Love wrote:
 
> Which brings me to the next point ... the trees are way out of sync. 
> When was the last time someone pushed an SH merge off to the official
> kernel?  Thankfully, Jeremy just merged official into SH but we need it
> the other way around now.

Welcome to the !x86 world. :)  (I'm almost sure you've had experiance
with another arch, but for the rest of the world soon to be joining...)
anything other than x86 will never be fully in sync anyhow.  The fun
part is idealy you sync up with a rev, pound it heavily and hope that
upstream hasn't changed a lot in the mean time.  Then you patch bomb. :)

Having said that, do any of the powers that be have plans to being
patchbombing marcelo (and maybe even linus? :))

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

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

[David W. <dw...@in...>]

rm...@te... said:
>  I _want_ per-arch definitions that optimize away the flushes that
> aren't needed!  Code should be written for the common denominator, and
> if arch X doesn't need Y, then it defines to nothing.

> I think that is what you want, too?

Absolutely. I just want them to have sensible names, that don't imply that 
they're actually going to flush the cache when they're not.

I'd rather have ifdefs than a flush_cache_page() which doesn't. But like you
and any other non-crack-smoking person, I'd rather have a sensibly named
routine which does the appropriate thing in each situation depending on the
caches of the CPU in question. 

> I just talked to Marcelo about merging into 2.4 ...

I saw.

--
dwmw2

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

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

On Wed, 2001-12-05 at 18:07, David Woodhouse wrote:

> I disagree. Having a flush_cache_range() function which does _less_ than 
> its name implies is a correctness problem. Having the per-arch ifdefs to 
> optimise away the flushes which aren't necessary, ugly though it may be, it 
> still better than that.

I _want_ per-arch definitions that optimize away the flushes that aren't
needed!  Code should be written for the common denominator, and if arch
X doesn't need Y, then it defines to nothing.

I think that is what you want, too?

> Provide a new function with a name that at least vaguely describes its 
> behaviour - and all will be well. 

I agree here ... its how we handle the per-arch mess I am speaking of.

> >  Nonetheless, we need documentation.  Even more important, the cml2
> > package is not synced to SH at all.  Ie, it won't work.  We need to
> > fix that (or not use cml2 <grin>). 
> 
> Surely we just need to make sure that our stuff is merged first? Then paint 
> it pink :)

I just talked to Marcelo about merging into 2.4 ...

	Robert Love

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

[David W. <dw...@in...>]

rm...@te... said:
>  I think the above is certainly better than having the ifdefs in the
> code itself.

I disagree. Having a flush_cache_range() function which does _less_ than 
its name implies is a correctness problem. Having the per-arch ifdefs to 
optimise away the flushes which aren't necessary, ugly though it may be, it 
still better than that.

Provide a new function with a name that at least vaguely describes its 
behaviour - and all will be well. 

>  Nonetheless, we need documentation.  Even more important, the cml2
> package is not synced to SH at all.  Ie, it won't work.  We need to
> fix that (or not use cml2 <grin>). 

Surely we just need to make sure that our stuff is merged first? Then paint 
it pink :)

--
dwmw2

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

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

On Wed, 2001-12-05 at 17:41, David Woodhouse wrote:

> The thing that does it for me is finding crap like
> #define flush_cache_range(mm, start, end)	do { } while (0)
> 
> I tried to _use_ that for dealing with flash chip state changes - and it's 
> hardly surprising it didn't work, is it? :)

I think the above is certainly better than having the ifdefs in the code
itself.

> Actually, it's not that hairy. I've made such a patch already, for building 
> the Red Hat RPM kernel for SH. It's quite clean.

Ah, good.  I'd like to see a merge with 2.4/2.5 mainstream, but I'd like
the maintainer's permission to start pushing bits.

> That is not an acceptable policy change. It will only go in if ESR sneaks it
> in as part of the switch to the CML2 mechanism. If it's submitted 
> separately and honestly, so that it can be discussed individually, I'm sure 
> it won't get accepted.

Good, I agree.  I've said as much in the past, at least, about cml2.

Nonetheless, we need documentation.  Even more important, the cml2
package is not synced to SH at all.  Ie, it won't work.  We need to fix
that (or not use cml2 <grin>).

	Robert Love

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

[David W. <dw...@in...>]

rm...@te... said:
>  I think the #if !defined(CONFIG_SH) is still enough to show a rewrite
> is needed.

The thing that does it for me is finding crap like
#define flush_cache_range(mm, start, end)	do { } while (0)

I tried to _use_ that for dealing with flash chip state changes - and it's 
hardly surprising it didn't work, is it? :)

rm...@te... said:
> 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). 

Actually, it's not that hairy. I've made such a patch already, for building 
the Red Hat RPM kernel for SH. It's quite clean.

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

That is not an acceptable policy change. It will only go in if ESR sneaks it
in as part of the switch to the CML2 mechanism. If it's submitted 
separately and honestly, so that it can be discussed individually, I'm sure 
it won't get accepted.

But we ought to make the help text catch up anyway.

--
dwmw2

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

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

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.

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

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

On Wed, 2001-12-05 at 13:03, Jeremy Siegel wrote:

> ...I think that to encourage a general API rewrite the ugliness has to be in
> the kernel.org tree; if it's only in the linuxsh tree only we will care.  If
> I had
> to compare #if 0 and #ifndef CONFIG_SUPERH I'd guess the latter would
> be more likely to be accepted.  (I know it's generally frowned upon anyway,
> but it might get someone thinking; the #if 0 submission would probably be
> banned outright.)

I think the #if !defined(CONFIG_SH) is still enough to show a rewrite is
needed.  We should really aim for no ifdefs in code if at all possible
-- the function/define definitions should provide the conditional
compiling.

> Another minor point: even in the linuxsh tree itself, using CONFIG helps
> make it clear that this is deliberate, and not leftover/experimental hackery.
> (Maybe that's one of the other "multiple reasons" Robert refers to;-)

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.  For instance, we can push the #if defined to the mainline
kernel.  We would have to wear a brown paper bag for a month if we sent
the #if 0 off.

Which brings me to the next point ... the trees are way out of sync. 
When was the last time someone pushed an SH merge off to the official
kernel?  Thankfully, Jeremy just merged official into SH but we need it
the other way around now.

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.

Second, with 2.5 starting, we need conversion to both CML2 and
kbuild-2.5.  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?  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...

I'm offering my help.  Comments?

	Robert Love

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

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

NIIBE Yutaka wrote:

> VIPT: Virtually Indexed Phisically Tagged cache.
>
> For break_cow, we don't need to flush the cache.  On some architecture
> where permission informatipn is there, we need to flush it because it
> was read-only before.  But it's not the case for SuperH.  If you want,
> please try to enable the flushing and see how the performance going
> down.
>
> For the case of do_wp_page, I think conditions still are applied.  The
> logic is same as break_cow.  On some architecture (not SuperH), it is
> needed, or else, the fault occurs again and again.

Thanks -- since I don't know enough about the memory management the
change from exclusive_swap_page() and delete_from_swap_cache() to
can_share_swap_page() made me wonder, but if you say it's still safe, I'm
quite happy to remove it as per your patch!

Robert Love wrote:

> For multiple reasons, shouldn't we do this:
>
> +#if !defined(CONFIG_SUPERH) /* this is not needed for VIPT cache */
>                         flush_cache_page(vma, address);
> +#endif

We'd do it that way in anything we distribute from mvista, of course, but
in the community tree I'd want to defer to the community.  However...

NIIBE Yutaka wrote:

> David Woodhouse wrote:
>  > 2.5 has opened. I think it's time to provide an API to the cache code that
>  > actually makes sense, and the functions bear some relation to their
>  > behaviour and the reasons for calling them.
>
> Yes, that is my point too.  Leave ugly thing as is so that people want
> to do better one.

...I think that to encourage a general API rewrite the ugliness has to be in
the kernel.org tree; if it's only in the linuxsh tree only we will care.  If
I had
to compare #if 0 and #ifndef CONFIG_SUPERH I'd guess the latter would
be more likely to be accepted.  (I know it's generally frowned upon anyway,
but it might get someone thinking; the #if 0 submission would probably be
banned outright.)

Another minor point: even in the linuxsh tree itself, using CONFIG helps
make it clear that this is deliberate, and not leftover/experimental hackery.
(Maybe that's one of the other "multiple reasons" Robert refers to;-)

--Jeremy Siegel

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

[David W. <dw...@in...>]

js...@mv... said:
>  Trying to keep the drop-in trees easy to drop in, over the last
> several days I've updated the 2.4 branch to 2.4.16 and the 2.5 branch
> to 2.5.0; before modifying the 2.4 branch I retagged it
> linux-2.4.13-pre2, so you can pull the old one with that tag.

Much stuff is still including <asm/segment.h>. We should send Linus/Marcelo 
a patch which removes that include from anything but arch-specific code. It 
shouldn't be required.

--
dwmw2

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

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

David Woodhouse wrote:
 > 2.5 has opened. I think it's time to provide an API to the cache code that 
 > actually makes sense, and the functions bear some relation to their 
 > behaviour and the reasons for calling them.

Yes, that is my point too.  Leave ugly thing as is so that people want
to do better one.

This treatment is the note for our project.
-- 

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

[David W. <dw...@in...>]

> +#if !defined(CONFIG_SUPERH) /* this is not needed for VIPT cache */
>                         flush_cache_page(vma, address); 
> +#endif 

Could there possibly be a more graphic demonstration of just how horribly 
stupid and broken the existing Linux cache management API currently is?

The fact that some architectures actually achieve what you're trying to do 
here by making flush_cache_page() a NOP doesn't help make things better, 
either :)

2.5 has opened. I think it's time to provide an API to the cache code that 
actually makes sense, and the functions bear some relation to their 
behaviour and the reasons for calling them.

Hint: Generic code, which knows nothing about how the CPU's cache works,
almost never actually _needs_ to flush a page. It normally only wants to
make sure there are no aliases with other virtual addresses in the dcache, 
or that code newly written through the dcache is present in the icache. 
Hence, the word 'flush' should no appear in the names of functions called 
from generic code.

So contemplate how sane it would be to have functions called
unalias_dcache_page_ram, unalias_dcache_page_icache, or something vaguely
representing the actual behaviour - then it's perfectly OK to have some of
them do nothing, and you can far more easily make sure the right ones are
called at the right times, and do the right things.

We really shouldn't need arch-specific ifdefs like that in common code.

--
dwmw2

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

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

On Tue, 2001-12-04 at 20:40, NIIBE Yutaka wrote:

> +#if 0 /* This is not needed for VIPT cache, performance goes bad if we flush */
>  			flush_cache_page(vma, address);
> +#endif

For multiple reasons, shouldn't we do this:

+#if !defined(CONFIG_SUPERH) /* this is not needed for VIPT cache */
                        flush_cache_page(vma, address);
+#endif

instead ?

	Robert Love

[linuxsh-dev] Drop-In tree updates

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

Here's a patch.

2001-12-05  NIIBE Yutaka  <gn...@m1...>

	* mm/memory.c (do_wp_page): Re-introduce ifdef-out-ing
	flush_cache_page.

Index: mm/memory.c
===================================================================
RCS file: /cvsroot/linuxsh/linux/mm/memory.c,v
retrieving revision 1.2
diff -u -3 -p -r1.2 memory.c
--- mm/memory.c	2001/12/03 22:15:35	1.2
+++ mm/memory.c	2001/12/05 01:38:12
@@ -917,7 +917,9 @@ static int do_wp_page(struct mm_struct *
 		int reuse = can_share_swap_page(old_page);
 		unlock_page(old_page);
 		if (reuse) {
+#if 0 /* This is not needed for VIPT cache, performance goes bad if we flush */
 			flush_cache_page(vma, address);
+#endif
 			establish_pte(vma, address, page_table, pte_mkyoung(pte_mkdirty(pte_mkwrite(pte))));
 			spin_unlock(&mm->page_table_lock);
 			return 1;	/* Minor fault */
-- 

[linuxsh-dev] Drop-In tree updates

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

Jeremy Siegel wrote:
 > drivers/net/8139too.c:

Will look into.

 > mm/memory.c:
 >   There were two places where the SH code ifdef'd out cache flush calls
 >   for performance, noting in comments that a VIPT cache doesn't require
 >   them.  The second of these was in do_wp_page(), and the code changed
 >   enough that I chose NOT to ifdef out that flush call, since I wasn't
 >   sure if the conditions that made it unnecessary still applied.

VIPT: Virtually Indexed Phisically Tagged cache.

For break_cow, we don't need to flush the cache.  On some architecture
where permission informatipn is there, we need to flush it because it
was read-only before.  But it's not the case for SuperH.  If you want,
please try to enable the flushing and see how the performance going
down.

For the case of do_wp_page, I think conditions still are applied.  The
logic is same as break_cow.  On some architecture (not SuperH), it is
needed, or else, the fault occurs again and again.

 > The other places where SH tweaks common code is a few insertions of
 > cache flush calls; include/linux/highmem.h:memclear_highpage_flush() and
 > kernel/ptrace.c:access_one_page() both add flush_dcache_page(page) right
 > before flush_page_to_ram(page).  And drivers/block/rd.c:initrd_read()
 > adds flush_cache_all() right after a copy_to_user() call.  I left all
 > these alone, assuming they're still necessary (cache aliasing issue?)
 > but Niibe may want them removed if they're no longer necessary?

Those are paranoia things which can be removed.
-- 

[linuxsh-dev] Drop-In tree updates

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

Hi folks,

Trying to keep the drop-in trees easy to drop in, over the last several
days I've updated the 2.4 branch to 2.4.16 and the 2.5 branch to 2.5.0;
before modifying the 2.4 branch I retagged it linux-2.4.13-pre2, so you
can pull the old one with that tag.

However: I only tested minimal SH3/SH4 Solution Engine platforms, so
other things may have broken (e.g. Robert Love already submitted a fix
for the gdrom, which apparently didn't even compile.)

In a couple cases, diffs to the SH tree conflicted with generic kernel
changes and they may not be correct now; those more familiar with these
specific portions of code may want to take a look at them...

drivers/net/8139too.c:
  Most SH changes (buffer size and DMA for Dreamcast) carried forward,
  except for the last one in rtl8139_start_xmit(), where USE_NO_DMAMAP
  forced an skb_copy_and_csum_dev() call.  The copy is now done all the
  time, so there was nowhere to put that check; I assume that's ok?
  (Come to think of it, that means USE_NO_DMAMAP could be removed.)

mm/memory.c:
  There were two places where the SH code ifdef'd out cache flush calls
  for performance, noting in comments that a VIPT cache doesn't require
  them.  The second of these was in do_wp_page(), and the code changed
  enough that I chose NOT to ifdef out that flush call, since I wasn't
  sure if the conditions that made it unnecessary still applied.

The other places where SH tweaks common code is a few insertions of
cache flush calls; include/linux/highmem.h:memclear_highpage_flush() and
kernel/ptrace.c:access_one_page() both add flush_dcache_page(page) right
before flush_page_to_ram(page).  And drivers/block/rd.c:initrd_read()
adds flush_cache_all() right after a copy_to_user() call.  I left all
these alone, assuming they're still necessary (cache aliasing issue?)
but Niibe may want them removed if they're no longer necessary?

--Jeremy Siegel

Re: [linuxsh-dev] [PATCH] gdrom compile fix

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

Robert Love wrote:

> Two problems prevent gdrom from compiling under kernel 2.4.16 (cvs
> module "linux" was recently updated to 2.4.16):
>
> - cdrom_fops global struct was removed in favor or per-driver structs
> declaring their block device functions. this patch adds a proper
> gdrom_bdops structure and uses it.
>
> - cdrom.c includes asm/segment.h.  arch-sh does not have the header.
> this patch adds a simple segment.h with no defines.  this is standard
> practice since segment.h is deprecated (see arch-ia64, for instance).
>
> Without this patch neither cdrom support in general or the gdrom driver
> in specific will compile on later kernels.  Can someone merge it into
> CVS?

Done for the linux-2_4-branch, will do head later.

[linuxsh-dev] [PATCH] gdrom compile fix

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

Two problems prevent gdrom from compiling under kernel 2.4.16 (cvs
module "linux" was recently updated to 2.4.16):

- cdrom_fops global struct was removed in favor or per-driver structs
declaring their block device functions. this patch adds a proper
gdrom_bdops structure and uses it.

- cdrom.c includes asm/segment.h.  arch-sh does not have the header. 
this patch adds a simple segment.h with no defines.  this is standard
practice since segment.h is deprecated (see arch-ia64, for instance).

Without this patch neither cdrom support in general or the gdrom driver
in specific will compile on later kernels.  Can someone merge it into
CVS?

Thanks,

	Robert Love

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

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

On Mon, 2001-12-03 at 16:16, Jeremy Siegel wrote:
> Just FYI... the preemptible kernel depends on non-preemptible critical regions
> denoted by spinlock calls (see Robert Love's excellent summary in
> Documentation/preempt-locking.txt).  Many common drivers are assumed to have
> correct locking for SMP operation, but non-SMP drivers may not. I've only run
> the PreK SH kernel on the Solution Engine w/Ethernet and serial, but I did not
> yet check to see if additional locks might be required in drivers/char/sh-sci.c
> or drivers/net/stnic.c, which are specific to SH platforms and thus not SMP-safe
> otherwise.

Ahh, good point.  Similar situation occured on ARM when it went
preemptive.  Thankfully, Russel King and company try to properly lock
things even if they are no ops.

Coding under a preemptive kernel means more than what
Documentation/preempt-locking.txt implies ... you have to protect data
regions as if you are operating under SMP.

It is good practice, anyhow.

This means you can include linux/spinlock.h and use the locking
constructs as needed.  Under a normal UP kernel, they will compile
away.  Under a preemptive kernel, they will provide the needed
reentrancy protection.  If there ever is a an SMP SH kernel (or
something like it) the kernel will be ready for the future.

	Robert Love

Re: [linuxsh-dev] Linux on Cassiopeia A21S

[Christian C. <Chr...@fn...>]

Andrei Shuvikov wrote:
> 
> Hi,
> I'm not sure this is the right place to ask but there is not much up-to-date
> information about linux-sh. I'd like to try to run linux on my Cassiopeia
> A21S (SH-3 80MHz, 16MB RAM, WinCE 2.0). Is it possible? What should I start
> with? I found some loaders (like shlo.exe) but didn't find either source or
> description for it. Is it available anywhere?
> Thanks for you help,
> Andrey.

Hi Andrey,

9 months ago I asked the same thing about Cassiopeia A20.
Probably both use the same custom companion chip Casio FM-7403 nobody
has doc on. If you know somebody at Casio's, perhaps,...

A week ago I ask the same thing about shlo and got no response :-(

Most (all ?) loaders don't run under WinCE 2.0 because they have been
compiled whith 2.11 SDK and use API not available with 2.0.

Sorry to break your hopes...

Christian

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

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

Just FYI... the preemptible kernel depends on non-preemptible critical regions
denoted by spinlock calls (see Robert Love's excellent summary in
Documentation/preempt-locking.txt).  Many common drivers are assumed to have
correct locking for SMP operation, but non-SMP drivers may not. I've only run
the PreK SH kernel on the Solution Engine w/Ethernet and serial, but I did not
yet check to see if additional locks might be required in drivers/char/sh-sci.c
or drivers/net/stnic.c, which are specific to SH platforms and thus not SMP-safe
otherwise.

--Jeremy

Robert Love wrote:

> The attached is the fully preemptible linux kernel patch, for the SH
> arch.  This work is thanks to Jeremy Siegel of MontaVista.
>
> You will need an SH-patched kernel tree, available from
> http://sf.net/projects/linuxsh -- the CVS module "linux" has a drop-in
> replacement for 2.4.16.
>
> You will need the base preempt-kernel patch, available from
> ftp://ftp.kernel.org/pub/linux/kernel/people/rml/preempt-kernel
>
> Feedback is desired.
>
>         Robert Love

[linuxsh-dev] Linux on Cassiopeia A21S

[Andrei S. <hy...@ho...>]

Hi,
I'm not sure this is the right place to ask but there is not much up-to-date 
information about linux-sh. I'd like to try to run linux on my Cassiopeia 
A21S (SH-3 80MHz, 16MB RAM, WinCE 2.0). Is it possible? What should I start 
with? I found some loaders (like shlo.exe) but didn't find either source or 
description for it. Is it available anywhere?
Thanks for you help,
Andrey.

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

Re: [linuxsh-dev] [PATCH] allow root device to be gdrom

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

* Robert Love <rm...@te...> on Fri, Nov 30, 2001:

> The following patch allows the gdrom to be specified as a root device
> (ie, root=3D/dev/gdrom on the command line) on the Dreamcast by adding an
> identifier for it to the root_dev_names struct.  Thus an initrd is no
> longer needed.
>=20
> It is against my tree but should apply to the current CVS.  Not too sure
> why no one ever found it missing before.  I don't know what it takes to
> get it merged, but please?
>=20

No problem, thanks for the patch.  I've applied it to branch, I'll apply it
to head in a few minutes.

I'll be trying out your preempt patches in a few :).

M. R.

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

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

ftp://ftp.kernel.org/pub/linux/kernel/people/rml/sh/sh-update-rml-2.4.16-1.patch

I went ahead and diffed 2.4.16 against the SH tree.  Thus you can patch
2.4.16 directly without checking into CVS.  Hopefully this might
encourage some testers.

ftp://ftp.kernel.org/pub/linux/kernel/people/rml/preempt-kernel/v2.4/preempt-kernel-rml-2.4.16-1.patch

ftp://ftp.kernel.org/pub/linux/kernel/people/rml/sh/preempt-kernel-sh-2.4.16-1.patch

The above is links to the preempt-kernel patch and the arch-sh specific
work.

Users need to patch 2.4.16 with the three patches above and enable
CONFIG_PREEMPT to create the preemptible kernel for SH.

	Robert Love