From: James Bottomley <James.Bottomley@SteelEye.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Kernel development list <linux-kernel@vger.kernel.org>
Subject: Re: Elimination of klists
Date: Sun, 11 Sep 2005 16:44:19 -0500 [thread overview]
Message-ID: <1126475059.4831.44.camel@mulgrave> (raw)
In-Reply-To: <Pine.LNX.4.44L0.0509111531470.25522-100000@netrider.rowland.org>
On Sun, 2005-09-11 at 15:35 -0400, Alan Stern wrote:
> I noticed that you recently posted some updates to the klist code,
> although I haven't looked to see how you are using the klists.
Yes, that was mainly to tie their reference counting model back to the
objects they actually embed. It was just fixing a thinko in the
implementation rather than changing anything fundamental about them.
> What do you think about eliminating klists entirely, and instead using
> regular lists protected by either a mutex or an rwsem? It would remove a
> good deal of overhead, and I think it wouldn't be hard to convert the
> driver core. Would this be feasible for the things you're doing?
Actually, the concept of a klist is quite nice, and the beauty is that
all the locking is internal to them, so users can't actually get it
wrong (I like interfaces like this).
Originally the driver model did precisely use an ordinary list and a
mutex. The problem was that we entangled the mutex in the actions taken
by things like device_for_each_child() which caused deadlocks ... most
noticeably in the transport classes; klists got us out of this.
James
next prev parent reply other threads:[~2005-09-11 21:44 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-11 19:35 Elimination of klists Alan Stern
2005-09-11 21:44 ` James Bottomley [this message]
2005-09-11 22:25 ` Andrew Morton
2005-09-11 23:37 ` James Bottomley
2005-09-12 14:29 ` Alan Stern
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=1126475059.4831.44.camel@mulgrave \
--to=james.bottomley@steeleye.com \
--cc=linux-kernel@vger.kernel.org \
--cc=stern@rowland.harvard.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 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.