From: "Richard B. Johnson" <root@chaos.analogic.com>
To: "Jinu M." <jinum@esntechnologies.co.in>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Device Driver for SMP
Date: Mon, 23 Feb 2004 11:57:12 -0500 (EST) [thread overview]
Message-ID: <Pine.LNX.4.53.0402231144210.602@chaos> (raw)
In-Reply-To: <1118873EE1755348B4812EA29C55A97212812C@esnmail.esntechnologies.co.in>
On Mon, 23 Feb 2004, Jinu M. wrote:
> Hi All,
>
> We have developed a PCI device driver which works well on both MAC
> (yellow dog) and x86 (RedHat) architectures.
> Now we need to provide the support for SMP machine. What generic
> changes will have to be made to the driver to get it working
> on a SMP machine.
>
> My first doubt is who takes care of the SMP support? Is it the kernel's
> job or the driver's job?
> As you can see I am not a guru at Linux device drivers, so I would
> be happy if you could provide me pointers or some good explanation
> on it.
>
> Thanks a lot!
> -Jinu
>
If the driver was properly written, there is nothing you need
to do to "convert" it to SMP. However, if the driver was written
using 'cli/sti' pairs to protect critical sections, you need
to rewrite those sections to use spin-locks.
OTOH, if the driver was written like a lot of so-called "perfectly
working..." drivers I've seen, you may need to start from scratch!
It all depends upon the techniques the writer used.
When you have two or more CPUs, you absolutely-positively need
to identify and protect critical sections of code. These are
the sections that would corrupt data, muck up hardware, or
otherwise screw up if two or more CPUs were executing the
code or messing with variables at nearly the same time.
For instance, let's say it took two instructions to hardware
to turn on an external light-bulb and no intermediate hardware
instructions were allowed between these two instructions. You
definately need to keep another CPU from touching the hardware
until these two instructions have completed. With only one
CPU, you can often write sloppy code because you know that
nothing else is going to touch your hardware until you are
done. Not so, with SMP machines.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.24 on an i686 machine (797.90 BogoMips).
Note 96.31% of all statistics are fiction.
prev parent reply other threads:[~2004-02-23 16:57 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-02-23 16:36 Jinu M.
2004-02-23 16:43 ` Arjan van de Ven
2004-02-23 16:57 ` Richard B. Johnson [this message]
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=Pine.LNX.4.53.0402231144210.602@chaos \
--to=root@chaos.analogic.com \
--cc=jinum@esntechnologies.co.in \
--cc=linux-kernel@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®