From: Robert Love <rml@tech9.net>
To: Jeremy Siegel <jsiegel@mvista.com>
Cc: linuxsh-dev@lists.sourceforge.net, linux-kernel@vger.kernel.org
Subject: Re: [linuxsh-dev] [PATCH] Preemptible kernel for SH
Date: 03 Dec 2001 17:18:07 -0500 [thread overview]
Message-ID: <1007417890.1303.4.camel@phantasy> (raw)
In-Reply-To: <3C0BEB90.16DC3749@mvista.com>
In-Reply-To: <1007261428.820.4.camel@phantasy> <3C0BEB90.16DC3749@mvista.com>
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
next prev parent reply other threads:[~2001-12-04 0:20 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-12-02 2:50 [PATCH] Preemptible kernel for SH Robert Love
2001-12-02 3:28 ` Robert Love
2001-12-03 21:16 ` [linuxsh-dev] " Jeremy Siegel
2001-12-03 22:18 ` Robert Love [this message]
2001-12-05 22:22 ` Robert Love
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1007417890.1303.4.camel@phantasy \
--to=rml@tech9.net \
--cc=jsiegel@mvista.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxsh-dev@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.