From: Rick Lindsley <ricklind@us.ibm.com>
To: viro@math.psu.edu
Cc: linux-kernel@vger.kernel.org, haveblue@us.ibm.com
Subject: removal of BKL from drivers ..
Date: Wed, 07 Nov 2001 15:40:33 -0800 [thread overview]
Message-ID: <200111072340.fA7NeX409526@eng4.beaverton.ibm.com> (raw)
As an outgrowth of the locking document I did a few months ago
(http://lse.sourceforge.net/lockhier), Dave Hansen (haveblue) and I
have been looking at the use of the BKL in the release() functions of
drivers to see if it was really needed. This isn't so much a
performance thing (although you can never really tell with the BKL :)
as a cleanliness thing. It would appear that while some of those
drivers could stand some SMP locking, using the BKL in the release
function (only) doesn't provide it. We've identified over 50 drivers
in which this can be removed, and are working on the patches (and
planning to contact the maintainers, per usual). We'll select a small
number of them and apply safe SMP locking to them as examples for those
who like to cut 'n' paste their drivers for new devices.
The advantage of these changes will be to aid any developer trying to
determine how the BKL may or may not interact with their code. With
these patches, there will be 50+ less cases to consider.
At the time, it appears that most of these lock/unlock pairs were
created just in case they were needed, since there wasn't time to
inspect each driver or contact each maintainer. Before we post these
patches, I thought I'd ask if in the time since Al Viro moved this out
here (July 2000) if anybody (especially him!) has found a *legitimate*
use of the BKL in the release() functions. (We have not found one.)
Rick
PS The patches, available in about a week or so barring complications,
will also be posted to the above sourceforge website.
reply other threads:[~2001-11-07 23:42 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=200111072340.fA7NeX409526@eng4.beaverton.ibm.com \
--to=ricklind@us.ibm.com \
--cc=haveblue@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=viro@math.psu.edu \
/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®