From: Rick Lindsley <ricklind@us.ibm.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: viro@math.psu.edu (Alexander Viro),
dave@sr71.net (David C. Hansen),
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] remove BKL from drivers' release functions
Date: Sat, 01 Dec 2001 02:06:59 -0800 [thread overview]
Message-ID: <200112011007.fB1A70429394@eng4.beaverton.ibm.com> (raw)
In-Reply-To: Your message of "Sat, 01 Dec 2001 09:52:57 GMT." <E16A6pN-0006d0-00@the-village.bc.nu>
This is why we have a development tree. Its moving things in the
right direction which is important. I suspect many drivers will
want to use semaphores rather than atomic counts however, to ensure
that an open doesn't complete while a previous release is still
shutting down hardware
Yes, the only successful application for atomic counts that I've seen
(in this context) is for exclusive open code that looks like
if (count++) {
count--;
return -EBUSY;
}
in the open routine and
count--;
in the release. If you want to do anything else as a result of that
count, you'll need additional locking because it could have changed a
nanosecond after it was (safely) incremented or decremented. You can't
count on it remaining that value after you check it.
release()s that want to shutdown the device, free memory, or take other
actions will want to employ either a spinlock (plain or r/w as
appropriate) or a sleeping semaphore to insure things remain stable
until those actions are complete.
Rick
next prev parent reply other threads:[~2001-12-01 10:07 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-11-28 23:05 David C. Hansen
2001-11-28 23:29 ` Andrew Morton
2001-11-28 23:42 ` David C. Hansen
2001-11-28 23:50 ` Robert Love
2001-11-28 23:36 ` Alan Cox
2001-11-28 23:32 ` David C. Hansen
2001-11-28 23:45 ` Russell King
2001-11-29 0:26 ` David C. Hansen
2001-11-29 0:37 ` Jeff Garzik
2001-11-29 0:41 ` Russell King
2001-11-29 1:33 ` David C. Hansen
2001-11-29 1:42 ` Jeff Garzik
2001-11-29 7:17 ` Oliver Neukum
2001-11-29 1:47 ` Alan Cox
2001-11-29 9:15 ` Russell King
2001-11-29 13:55 ` BALBIR SINGH
2001-11-30 19:30 ` Rick Lindsley
2001-11-30 9:57 ` Alexander Viro
2001-11-30 12:41 ` Victor Yodaiken
2001-11-30 20:02 ` Rick Lindsley
2001-11-30 19:38 ` David C. Hansen
2001-11-30 23:12 ` Alexander Viro
2001-12-01 0:47 ` Rick Lindsley
2001-12-01 9:52 ` Alan Cox
2001-12-01 10:06 ` Rick Lindsley [this message]
2001-11-30 20:11 ` Rick Lindsley
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=200112011007.fB1A70429394@eng4.beaverton.ibm.com \
--to=ricklind@us.ibm.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=dave@sr71.net \
--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®