From: Greg KH <greg@kroah.com>
To: "Artem B. Bityutskiy" <dedekind@yandex.ru>
Cc: linux-kernel <linux-kernel@vger.kernel.org>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [Bug? Report] kref problem
Date: Thu, 16 Mar 2006 10:20:18 -0800 [thread overview]
Message-ID: <20060316182018.GA4301@kroah.com> (raw)
In-Reply-To: <4419A9B8.8060102@yandex.ru>
On Thu, Mar 16, 2006 at 09:08:56PM +0300, Artem B. Bityutskiy wrote:
> Greg KH wrote:
> >If you use decl_subsys(), you should be fine for this. Use that instead
> >of trying to roll your own subsystem kobjects please. That
> >infrastructure was written for a reason...
> Ok, I see, thanks. I just thought that this subsystem stuff will oblige
> me to use the device/driver/bus model which does not suit me.
decl_subsys() is in the sysfs.h header file, not the device.h file.
Just stay away from anything in there if you hate the driver core so
much :)
> >Data (kobjects) have a different lifespan than code (modules).
> >Seperating them is a good idea, and if not, your reference counting
> >issues can be quite nasty. See the recent EDAC fiasco for a good
> >example of how easy it is to mess things up in this manner.
>
> My logic was that the lifetime of that kobject = lifetime of my module
> because I cannot remove the module because every it's user increments
> the module's refcount. So, if refcount of my module is zero then the
> kobject's refcount is zero. Why this doesn't this work?
It "should" work in theory, but in real-life, the odds of getting all of
that lifetime logic correct... :)
You can do it, but in general, it's easier to think about kobjects as
being dynamic devices, as that is what they are. So making them dynamic
for real is a better thing to do to reinforce that principle.
Again, what are you doing that you can't use the driver core for?
thanks,
greg k-h
next prev parent reply other threads:[~2006-03-16 18:20 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-16 11:41 [Bug? Report] kref problem Artem B. Bityutskiy
2006-03-16 16:47 ` Greg KH
2006-03-16 16:50 ` Greg KH
2006-03-16 16:50 ` Artem B. Bityutskiy
2006-03-16 16:53 ` Greg KH
2006-03-16 17:07 ` Artem B. Bityutskiy
2006-03-16 17:10 ` Artem B. Bityutskiy
2006-03-16 17:20 ` Greg KH
2006-03-16 18:00 ` Artem B. Bityutskiy
2006-03-16 18:10 ` Greg KH
2006-03-16 17:18 ` Greg KH
2006-03-16 17:31 ` Dave Hansen
2006-03-16 17:42 ` Greg KH
2006-03-16 17:45 ` Artem B. Bityutskiy
2006-03-16 17:58 ` Greg KH
2006-03-16 18:08 ` Artem B. Bityutskiy
2006-03-16 18:20 ` Greg KH [this message]
2006-03-17 9:30 ` Artem B. Bityutskiy
2006-03-17 15:18 ` Greg KH
2006-03-17 16:34 ` Artem B. Bityutskiy
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=20060316182018.GA4301@kroah.com \
--to=greg@kroah.com \
--cc=dedekind@yandex.ru \
--cc=linux-kernel@vger.kernel.org \
--cc=tglx@linutronix.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 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.