From: Tejun Heo <teheo@suse.de>
To: NeilBrown <neilb@suse.de>
Cc: Greg Kroah-Hartman <gregkh@suse.de>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/3] refcounting improvements in sysfs.
Date: Fri, 26 Mar 2010 14:10:28 +0900 [thread overview]
Message-ID: <4BAC41C4.4040900@suse.de> (raw)
In-Reply-To: <4BAC3CE0.2010408@suse.de>
One thing to add.
On 03/26/2010 01:49 PM, Tejun Heo wrote:
> Nice article. In general, yeap, I agree it would be nice to have a
> working reference count abstraction. However, kref along with kobject
> is a good example of obscurity by abstraction anti pattern. :-)
I think one of the reasons why k* hasn't really worked as well as it
was orginally imagined to do is the way we - the kernel programmers -
think and work. We add abstractions when something is functionally
necessary, so in a lot of cases the functional requirements become the
implementation and the communication among us (ie. serves as implied
documentation). The k* stuff detracts from this principle. Those
abstractions are there for the purpose of abstracting and our usual
mindset becomes very susceptible to misinterpretations as no easily
identifiable functional requirements are there - we either end up
imaginging something up or waste time frustrated trying to figure out
why the hell that abstraction is there.
This actualy is a very generic problem. When a LOT of people are
trying to work together sharing a lot of infrastructures, it is very
deterimental to impose certain paradigm upon them. People can easily
agree upon functional necessities but one guy's wildest, most
ambitious paradigmatic vision looks like a complete bull to another
gal.
So, let's keep the abstractions to the just necessary level and
communicate at the functional layer. In this case, mount and sysfs
shares the requirement for a refcount w/ a kill switch. I'm not sure
it warrants common abstraction at this stage but if the *function* can
be wrapped nicely along with lockdep annotations and all, why not?
Thanks.
--
tejun
next prev parent reply other threads:[~2010-03-26 5:10 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-24 3:20 [PATCH 0/3] refcounting improvements in sysfs NeilBrown
2010-03-24 3:20 ` [PATCH 1/3] sysfs: simplify handling for s_active refcount NeilBrown
2010-03-26 4:24 ` Eric W. Biederman
2010-03-26 5:32 ` Neil Brown
2010-03-26 5:42 ` Tejun Heo
2010-03-26 7:53 ` Eric W. Biederman
2010-03-29 4:43 ` Neil Brown
2010-03-29 7:47 ` Neil Brown
2010-03-24 3:20 ` [PATCH 3/3] kref: create karef and use for sysfs_dirent->s_active NeilBrown
2010-03-26 4:50 ` Eric W. Biederman
2010-03-24 3:20 ` [PATCH 2/3] sysfs: make s_count a kref NeilBrown
2010-03-26 4:29 ` Eric W. Biederman
2010-03-26 3:10 ` [PATCH 0/3] refcounting improvements in sysfs Eric W. Biederman
2010-03-26 3:28 ` Neil Brown
2010-03-26 4:49 ` Tejun Heo
2010-03-26 5:10 ` Tejun Heo [this message]
2010-03-26 6:02 ` Neil Brown
2010-03-26 6:32 ` Tejun Heo
2010-03-29 5:10 ` Neil Brown
2010-03-31 3:20 ` Tejun Heo
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=4BAC41C4.4040900@suse.de \
--to=teheo@suse.de \
--cc=gregkh@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=neilb@suse.de \
/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