linux-ide.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Greg KH <gregkh@suse.de>
To: Tejun Heo <htejun@gmail.com>
Cc: James Bottomley <James.Bottomley@SteelEye.com>,
	hugh@veritas.com, cornelia.huck@de.ibm.com,
	dmitry.torokhov@gmail.com, oneukum@suse.de, maneesh@in.ibm.com,
	rpurdie@rpsys.net, Jeff Garzik <jgarzik@pobox.com>,
	lkml <linux-kernel@vger.kernel.org>,
	"linux-ide@vger.kernel.org" <linux-ide@vger.kernel.org>,
	SCSI Mailing List <linux-scsi@vger.kernel.org>
Subject: Re: [RFD driver-core] Lifetime problems of the current driver model
Date: Fri, 30 Mar 2007 10:41:58 -0700	[thread overview]
Message-ID: <20070330174158.GB4469@suse.de> (raw)
In-Reply-To: <460D12B8.6050101@gmail.com>

On Fri, Mar 30, 2007 at 10:38:00PM +0900, Tejun Heo wrote:
> James Bottomley wrote:
> > On Fri, 2007-03-30 at 18:43 +0900, Tejun Heo wrote:
> >> Orphaning sysfs nodes on unregistration is a big step in this
> >> direction.  With sysfs reference counting out of the picture,
> >> implementing 'disconnect immediate' interface only on a few components
> >> (including request_queue) should suffice for most block device
> >> drivers.  I'm not familiar with other drivers but I don't think
> >> they'll be very different.
> > 
> > I agree with this statement.  The big question in my mind is how do we
> > do it?
> > 
> > The essential problem, and the reason why the lifetime rules are
> > entangled is that fundamentally, sysfs entries are managed by kobjects.
> > The things the device drivers are interested in is struct device, which
> > is usually embedded in driver data structures.  Unfortunately, the
> > required kobject is usually embedded in struct device meaning that the
> > relevant driver structure cannot be freed while the sysfs entry still
> > exists.
> > 
> > It seems to me that the only way to Orphan the sysfs entries is to
> > separate the kobject and the struct device so their lifetime rules are
> > no longer entangled.  Then we can free the driver structure with the
> > embedded struct device while still keeping the necessary kobject around
> > to perform orphaned sysfs operations.
> > 
> > So it seems to me that what we need to do is to give struct device its
> > own kref and a pointer to a kobject.  Then we can manage the separate
> > lifetimes independently.  The device would basically allocate and take a
> > reference to the kobject on device_add() and relinquish it again (and
> > null out the kobject pointer) on device_del().  The complexity here is
> > that we now have to allocate the kobject somewhere else ... probably in
> > device_add() (it doesn't come for free with the device structures).
> 
> My plan was to make sysfs more independent from struct device/kobject.
> e.g. Something like the following.
> 
> * kobject_get() on attr/symlink creation
> * open() doesn't need extra kobject reference
> * deleting a node makes it release the kobject reference and the kobject
> pointer is nullified.

Hm, this sounds good, but I think it will be racy.

Although separating the very tight tie between sysfs and kobject would
be very good to have.  Pat originally wanted to do that years ago,
but he's now lost to the land of a million sheep...

So I don't object to this goal at all.

> This way the sysfs reference counting can be put completely out of
> picture without impacting the rest of code.  Handling symlink and
> suicidal attributes might need some extra attention but I think they can
> be done.

Ok, I'll but I really want to see that code :)

> In the long term, I think sysfs should be independent from driver model
> and kobject such that an entity which wants to use sysfs but is not a
> device doesn't have to dance with kobject just to use sysfs.

I agree.

thanks,

greg k-h

  parent reply	other threads:[~2007-03-30 17:43 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <460CDBA6.5030608@gmail.com>
2007-03-30 12:29 ` [RFD driver-core] Lifetime problems of the current driver model James Bottomley
2007-03-30 13:15   ` Dmitry Torokhov
2007-03-30 13:38   ` Tejun Heo
     [not found]   ` <d120d5000703300615y7b367d82hb42f1c58ca8a6328@mail.gmail.com>
2007-03-30 17:58     ` James Bottomley
2007-03-30 18:18       ` Dmitry Torokhov
     [not found]   ` <460D12B8.6050101@gmail.com>
2007-03-30 17:41     ` Greg KH [this message]
2007-03-30 18:19     ` James Bottomley
2007-04-01 19:59       ` Tejun Heo
2007-04-02  9:20         ` Cornelia Huck
2007-04-02 15:34           ` Cornelia Huck
2007-04-03  3:08             ` Tejun Heo
2007-04-02  9:33         ` Greg KH
2007-04-02 12:10         ` Maneesh Soni
2007-04-02 19:33       ` Luben Tuikov
2007-03-30 13:19 ` Cornelia Huck
2007-03-30 13:19   ` Tejun Heo
2007-03-30 13:40     ` Cornelia Huck
2007-03-30 13:58       ` Tejun Heo
2007-03-30 14:52         ` Cornelia Huck
2007-03-30 15:08           ` Tejun Heo
2007-03-30 19:31             ` Cornelia Huck
2007-03-31  3:12               ` Tejun Heo
2007-03-31  3:15                 ` Tejun Heo
2007-03-31 16:08                 ` Cornelia Huck
2007-03-31 16:14                   ` Tejun Heo
2007-04-02 19:24                 ` Luben Tuikov
2007-03-30 17:38 ` Greg KH
2007-03-30  9:43 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=20070330174158.GB4469@suse.de \
    --to=gregkh@suse.de \
    --cc=James.Bottomley@SteelEye.com \
    --cc=cornelia.huck@de.ibm.com \
    --cc=dmitry.torokhov@gmail.com \
    --cc=htejun@gmail.com \
    --cc=hugh@veritas.com \
    --cc=jgarzik@pobox.com \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=maneesh@in.ibm.com \
    --cc=oneukum@suse.de \
    --cc=rpurdie@rpsys.net \
    /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;
as well as URLs for NNTP newsgroup(s).