Hello, all.
This document tries to describe lifetime problems of the current
device driver model primarily from the point view of device drivers
and establish consensus, or at least, start discussion about how to
solve these problems. This is primarily based on my experience with
IDE and SCSI la
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
Hi James,
On 3/30/07, James Bottomley <[EMAIL PROTECTED]> 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 onl
On Fri, 30 Mar 2007 18:43:02 +0900,
Tejun Heo <[EMAIL PROTECTED]> wrote:
> One way to solve this problem is to subordinate lifetime rule #b to
> rule #c. Each kobject points to its owning module such that grabbing
> a kobject automatically grabs the module. The problem with this
> approach is th
Cornelia Huck wrote:
> On Fri, 30 Mar 2007 18:43:02 +0900,
> Tejun Heo <[EMAIL PROTECTED]> wrote:
>
>> One way to solve this problem is to subordinate lifetime rule #b to
>> rule #c. Each kobject points to its owning module such that grabbing
>> a kobject automatically grabs the module. The prob
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 requ
On Fri, 30 Mar 2007 22:19:52 +0900,
Tejun Heo <[EMAIL PROTECTED]> wrote:
> > Shouldn't getting/putting the module refcount be solely done in
> > kobject.c? Grab the module reference when the kobject is created and
> > release the module reference in kobject_cleanup() after the release
> > function
Cornelia Huck wrote:
> On Fri, 30 Mar 2007 22:19:52 +0900,
> Tejun Heo <[EMAIL PROTECTED]> wrote:
>
>>> Shouldn't getting/putting the module refcount be solely done in
>>> kobject.c? Grab the module reference when the kobject is created and
>>> release the module reference in kobject_cleanup() aft
On Fri, 30 Mar 2007 22:58:39 +0900,
Tejun Heo <[EMAIL PROTECTED]> wrote:
> It's a little bit more convoluted than that. Module reference count of
> zero doesn't indicate that there is no one referencing the module. It
> just means that the module can be unloaded. ie. There still can be any
> nu
Cornelia Huck wrote:
> On Fri, 30 Mar 2007 22:58:39 +0900,
> Tejun Heo <[EMAIL PROTECTED]> wrote:
>
>> It's a little bit more convoluted than that. Module reference count of
>> zero doesn't indicate that there is no one referencing the module. It
>> just means that the module can be unloaded. i
On Fri, Mar 30, 2007 at 06:43:02PM +0900, Tejun Heo wrote:
> Hello, all.
>
> This document tries to describe lifetime problems of the current
> device driver model primarily from the point view of device drivers
> and establish consensus, or at least, start discussion about how to
> solve these pr
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 'discon
On Fri, 2007-03-30 at 09:15 -0400, Dmitry Torokhov wrote:
> If you want to manage lifetime rules independently you might want to
> not embed struct device into you subsystems objects but attach them
> via pointers and use device_create(). Now that we orphan sysfs access
> upon unregistering device
On 3/30/07, James Bottomley <[EMAIL PROTECTED]> wrote:
On Fri, 2007-03-30 at 09:15 -0400, Dmitry Torokhov wrote:
> If you want to manage lifetime rules independently you might want to
> not embed struct device into you subsystems objects but attach them
> via pointers and use device_create(). Now
On Fri, 2007-03-30 at 22:38 +0900, Tejun Heo wrote:
> My plan was to make sysfs more independent from struct device/kobject.
> e.g. Something like the following.
That's sort of what I was reaching for too ... it just looks to me that
all the sysfs glue is in kobject, so they make a good candidate
On Sat, 31 Mar 2007 00:08:19 +0900,
Tejun Heo <[EMAIL PROTECTED]> wrote:
> (3) make sure all existing kobjects are released by module exit function.
>
> For example, let's say there is a hypothetical disk device /dev/dk0
> driven by a hypothetical driver mydrv. /dev/dk0 is represented like the
>
Cornelia Huck wrote:
> On Sat, 31 Mar 2007 00:08:19 +0900,
> Tejun Heo <[EMAIL PROTECTED]> wrote:
>
>> (3) make sure all existing kobjects are released by module exit function.
>>
>> For example, let's say there is a hypothetical disk device /dev/dk0
>> driven by a hypothetical driver mydrv. /dev
Tejun Heo wrote:
> Cornelia Huck wrote:
>> On Sat, 31 Mar 2007 00:08:19 +0900,
>> Tejun Heo <[EMAIL PROTECTED]> wrote:
>>
>>> (3) make sure all existing kobjects are released by module exit function.
>>>
>>> For example, let's say there is a hypothetical disk device /dev/dk0
>>> driven by a hypothe
On Sat, 31 Mar 2007 12:12:48 +0900,
Tejun Heo <[EMAIL PROTECTED]> wrote:
> > Hm, but as long as dk0 is registered, it can be looked up and someone
> > could get a reference on it.
>
> Yeah, exactly. That's why any getting any kobject reference backed by a
> module must be accompanied by try_modu
Cornelia Huck wrote:
On Sat, 31 Mar 2007 12:12:48 +0900,
Tejun Heo <[EMAIL PROTECTED]> wrote:
Hm, but as long as dk0 is registered, it can be looked up and someone
could get a reference on it.
Yeah, exactly. That's why any getting any kobject reference backed by a
module must be accompanied b
Hello, James, Greg.
On Fri, Mar 30, 2007 at 01:19:34PM -0500, James Bottomley wrote:
> That's sort of what I was reaching for too ... it just looks to me that
> all the sysfs glue is in kobject, so they make a good candidate for the
> pure sysfs objects. Whatever we do, there has to be breakable
On Mon, 2 Apr 2007 04:59:43 +0900,
Tejun Heo <[EMAIL PROTECTED]> wrote:
> Okay, here's preliminary patch. I've tested it very lightly so it's
> likely to contain bugs and definitely needs to be splitted.
Cool. However, there's something fishy there (not sure whether it's in
your patch or a laten
On Mon, Apr 02, 2007 at 04:59:43AM +0900, Tejun Heo wrote:
>
> Dependencies between sysfs/kobject objects are clearer now and I think
> I got the locking and referencing correct. This patch immediately
> fixes 'sysfs attr grabbing the wrong kobject and module' problem -
> sysfs and module lifetim
On Mon, Apr 02, 2007 at 04:59:43AM +0900, Tejun Heo wrote:
> Hello, James, Greg.
>
> On Fri, Mar 30, 2007 at 01:19:34PM -0500, James Bottomley wrote:
> > That's sort of what I was reaching for too ... it just looks to me that
> > all the sysfs glue is in kobject, so they make a good candidate for
On Mon, 2 Apr 2007 11:20:48 +0200,
Cornelia Huck <[EMAIL PROTECTED]> wrote:
> Cool. However, there's something fishy there (not sure whether it's in
> your patch or a latent bug in the ccw bus code that just has been
> uncovered):
Similar bug when loading/unloading a module that creates a driver
--- Tejun Heo <[EMAIL PROTECTED]> wrote:
> Cornelia Huck wrote:
> > On Sat, 31 Mar 2007 00:08:19 +0900,
> > Tejun Heo <[EMAIL PROTECTED]> wrote:
> >
> >> (3) make sure all existing kobjects are released by module exit function.
> >>
> >> For example, let's say there is a hypothetical disk device /
--- James Bottomley <[EMAIL PROTECTED]> wrote:
> I'd favour trying to separate kobject and struct device for this ...
> move all the sysfs stuff into kobject and device only stuff into struct
^^^
Currently the kobject implementation is pure and well-defined. I
Cornelia Huck wrote:
> On Mon, 2 Apr 2007 11:20:48 +0200,
> Cornelia Huck <[EMAIL PROTECTED]> wrote:
>
>> Cool. However, there's something fishy there (not sure whether it's in
>> your patch or a latent bug in the ccw bus code that just has been
>> uncovered):
>
> Similar bug when loading/unloadi
28 matches
Mail list logo
