[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1175257751.3760.19.camel@mulgrave.il.steeleye.com>
Date: Fri, 30 Mar 2007 08:29:10 -0400
From: James Bottomley <James.Bottomley@...elEye.com>
To: Tejun Heo <htejun@...il.com>
Cc: gregkh@...e.de, hugh@...itas.com, cornelia.huck@...ibm.com,
dmitry.torokhov@...il.com, oneukum@...e.de, maneesh@...ibm.com,
rpurdie@...ys.net, Jeff Garzik <jgarzik@...ox.com>,
lkml <linux-kernel@...r.kernel.org>,
"linux-ide@...r.kernel.org" <linux-ide@...r.kernel.org>,
SCSI Mailing List <linux-scsi@...r.kernel.org>
Subject: Re: [RFD driver-core] Lifetime problems of the current driver model
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).
James
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists