On Thu, 26 Apr 2007 10:58:45 -0400 (EDT),
Alan Stern <[EMAIL PROTECTED]> wrote:
> > > > The remove() method must also unset driver_data.
> > >
> > > It doesn't really have to. The driver core could do it.
> >
> > I think it is more consistent if the driver takes care of the fields
> >
On Thu, 26 Apr 2007, Cornelia Huck wrote:
> On Wed, 25 Apr 2007 16:13:12 -0400 (EDT),
> Alan Stern <[EMAIL PROTECTED]> wrote:
>
> > > Documentation/driver-model/lifetime-rules.txt?
> >
> > When (if) such a file is added, it should contain more than just these few
> > paragraphs.
>
> This file
On Wed, 25 Apr 2007 16:13:12 -0400 (EDT),
Alan Stern <[EMAIL PROTECTED]> wrote:
> > Documentation/driver-model/lifetime-rules.txt?
>
> When (if) such a file is added, it should contain more than just these few
> paragraphs.
This file may be a good idea in general. I'll see if I can come up
On Wed, 25 Apr 2007 16:13:12 -0400 (EDT),
Alan Stern [EMAIL PROTECTED] wrote:
Documentation/driver-model/lifetime-rules.txt?
When (if) such a file is added, it should contain more than just these few
paragraphs.
This file may be a good idea in general. I'll see if I can come up with
On Thu, 26 Apr 2007, Cornelia Huck wrote:
On Wed, 25 Apr 2007 16:13:12 -0400 (EDT),
Alan Stern [EMAIL PROTECTED] wrote:
Documentation/driver-model/lifetime-rules.txt?
When (if) such a file is added, it should contain more than just these few
paragraphs.
This file may be a good
On Thu, 26 Apr 2007 10:58:45 -0400 (EDT),
Alan Stern [EMAIL PROTECTED] wrote:
The remove() method must also unset driver_data.
It doesn't really have to. The driver core could do it.
I think it is more consistent if the driver takes care of the fields
specifically designed for
On Wed, 25 Apr 2007, Cornelia Huck wrote:
> On Tue, 24 Apr 2007 15:38:12 -0400 (EDT),
> Alan Stern <[EMAIL PROTECTED]> wrote:
>
> > We ought to make it explicitly clear that _all_ subsystems should behave
> > this way. Maybe it isn't necessary to go as far as having device_del()
> > call itself
On Tue, 24 Apr 2007 15:38:12 -0400 (EDT),
Alan Stern <[EMAIL PROTECTED]> wrote:
> We ought to make it explicitly clear that _all_ subsystems should behave
> this way. Maybe it isn't necessary to go as far as having device_del()
> call itself recursively; doing that would open up lots of possible
On Tue, 24 Apr 2007 15:38:12 -0400 (EDT),
Alan Stern [EMAIL PROTECTED] wrote:
We ought to make it explicitly clear that _all_ subsystems should behave
this way. Maybe it isn't necessary to go as far as having device_del()
call itself recursively; doing that would open up lots of possible
On Wed, 25 Apr 2007, Cornelia Huck wrote:
On Tue, 24 Apr 2007 15:38:12 -0400 (EDT),
Alan Stern [EMAIL PROTECTED] wrote:
We ought to make it explicitly clear that _all_ subsystems should behave
this way. Maybe it isn't necessary to go as far as having device_del()
call itself
On Sun, 22 Apr 2007, Greg KH wrote:
> > Looking some more, kobject_get_path() is used for kobject renaming,
> > uevent handling, and a little bit in the input core. None of these things
> > should try to access a kobject after it has been del()ed. After all, it's
> > no longer present in the
On Sun, 22 Apr 2007, Greg KH wrote:
Looking some more, kobject_get_path() is used for kobject renaming,
uevent handling, and a little bit in the input core. None of these things
should try to access a kobject after it has been del()ed. After all, it's
no longer present in the
On Mon, 23 Apr 2007, Cornelia Huck wrote:
> On Sun, 22 Apr 2007 10:40:51 -0700,
> Greg KH <[EMAIL PROTECTED]> wrote:
>
> > > Looking some more, kobject_get_path() is used for kobject renaming,
> > > uevent handling, and a little bit in the input core. None of these
> > > things
> > > should
On Sun, 22 Apr 2007 10:40:51 -0700,
Greg KH <[EMAIL PROTECTED]> wrote:
> > Looking some more, kobject_get_path() is used for kobject renaming,
> > uevent handling, and a little bit in the input core. None of these things
> > should try to access a kobject after it has been del()ed. After all,
On Mon, Apr 23, 2007 at 03:40:21PM +0900, Tejun Heo wrote:
> Hello, Dmitry.
>
> Dmitry Torokhov wrote:
> > Isn't think a good thing? By decoupling the 2 layers we insulate them
> > from changes in each other. This allows bug subsystems to concentrate
> > on topics that important to them instead
Hello, Dmitry.
Dmitry Torokhov wrote:
> Isn't think a good thing? By decoupling the 2 layers we insulate them
> from changes in each other. This allows bug subsystems to concentrate
> on topics that important to them instead of worying about refcounting
> objects that are not directly interesting
Hello, Dmitry.
Dmitry Torokhov wrote:
Isn't think a good thing? By decoupling the 2 layers we insulate them
from changes in each other. This allows bug subsystems to concentrate
on topics that important to them instead of worying about refcounting
objects that are not directly interesting for
On Mon, Apr 23, 2007 at 03:40:21PM +0900, Tejun Heo wrote:
Hello, Dmitry.
Dmitry Torokhov wrote:
Isn't think a good thing? By decoupling the 2 layers we insulate them
from changes in each other. This allows bug subsystems to concentrate
on topics that important to them instead of worying
On Sun, 22 Apr 2007 10:40:51 -0700,
Greg KH [EMAIL PROTECTED] wrote:
Looking some more, kobject_get_path() is used for kobject renaming,
uevent handling, and a little bit in the input core. None of these things
should try to access a kobject after it has been del()ed. After all, it's
On Mon, 23 Apr 2007, Cornelia Huck wrote:
On Sun, 22 Apr 2007 10:40:51 -0700,
Greg KH [EMAIL PROTECTED] wrote:
Looking some more, kobject_get_path() is used for kobject renaming,
uevent handling, and a little bit in the input core. None of these
things
should try to access a
On Sat, Apr 21, 2007 at 05:36:51PM -0400, Alan Stern wrote:
> On Fri, 20 Apr 2007, Greg KH wrote:
>
> > > Greg, do you know of anything in particular that depends on a kobjects
> > > not
> > > being released before their children are released?
> >
> > Yes, the whole driver model :)
>
> But
On Sat, Apr 21, 2007 at 05:36:51PM -0400, Alan Stern wrote:
On Fri, 20 Apr 2007, Greg KH wrote:
Greg, do you know of anything in particular that depends on a kobjects
not
being released before their children are released?
Yes, the whole driver model :)
But anything in
On Fri, 20 Apr 2007, Greg KH wrote:
> > Greg, do you know of anything in particular that depends on a kobjects not
> > being released before their children are released?
>
> Yes, the whole driver model :)
But anything in particular? Looking through the source code, I see
kobj->parent gets
On Fri, 20 Apr 2007, Dmitry Torokhov wrote:
> On 4/19/07, Alan Stern <[EMAIL PROTECTED]> wrote:
> >
> > Among the worst offenders are character devices. None of the subsystem
> > providers offering char device registration performs immediate detach --
> > they are a lot like sysfs used to be.
On Fri, 20 Apr 2007, Dmitry Torokhov wrote:
> On 4/20/07, Alan Stern <[EMAIL PROTECTED]> wrote:
> >
> > Dmitry, in thinking things over some more I realized there's going to be a
> > problem with the autosuspend support in USB. It has to do with the way a
> > driver needs to prevent (or block)
On Fri, 20 Apr 2007, Dmitry Torokhov wrote:
On 4/20/07, Alan Stern [EMAIL PROTECTED] wrote:
Dmitry, in thinking things over some more I realized there's going to be a
problem with the autosuspend support in USB. It has to do with the way a
driver needs to prevent (or block) suspends
On Fri, 20 Apr 2007, Dmitry Torokhov wrote:
On 4/19/07, Alan Stern [EMAIL PROTECTED] wrote:
Among the worst offenders are character devices. None of the subsystem
providers offering char device registration performs immediate detach --
they are a lot like sysfs used to be. (In fact,
On Fri, 20 Apr 2007, Greg KH wrote:
Greg, do you know of anything in particular that depends on a kobjects not
being released before their children are released?
Yes, the whole driver model :)
But anything in particular? Looking through the source code, I see
kobj-parent gets used
On Fri, Apr 20, 2007 at 11:40:39AM -0400, Alan Stern wrote:
> Here's a patch to do what I mentioned earlier. Not tested -- it may
> expose some existing bugs. It may even break something, but I'm not aware
> of anything that depends on it explicitly.
>
> Greg, do you know of anything in
On 4/20/07, Tejun Heo <[EMAIL PROTECTED]> wrote:
Hello, Dmitry.
Dmitry Torokhov wrote:
>> Many drivers (at least all the SCSI/IDE ones) consider struct device as
>> the base class of the devices those drivers implement. I don't think we
>> can just consider those drivers to be wrong.
>
> I am
Hello, Dmitry.
Dmitry Torokhov wrote:
>> Many drivers (at least all the SCSI/IDE ones) consider struct device as
>> the base class of the devices those drivers implement. I don't think we
>> can just consider those drivers to be wrong.
>
> I am not saying they are wrong I am just saying that
On 4/19/07, Alan Stern <[EMAIL PROTECTED]> wrote:
Among the worst offenders are character devices. None of the subsystem
providers offering char device registration performs immediate detach --
they are a lot like sysfs used to be. (In fact, they probably _can't_
provide it since read() or
Hi Tejun,
On 4/20/07, Tejun Heo <[EMAIL PROTECTED]> wrote:
Hello, Dmitry.
Dmitry Torokhov wrote:
> On 4/19/07, Cornelia Huck <[EMAIL PROTECTED]> wrote:
>> On Thu, 19 Apr 2007 09:13:43 -0400,
>> "Dmitry Torokhov" <[EMAIL PROTECTED]> wrote:
>>
>> > Because they are managed by 2 different
On 4/20/07, Alan Stern <[EMAIL PROTECTED]> wrote:
Dmitry, in thinking things over some more I realized there's going to be a
problem with the autosuspend support in USB. It has to do with the way a
driver needs to prevent (or block) suspends from occurring while it is
actively using a device.
Here's a patch to do what I mentioned earlier. Not tested -- it may
expose some existing bugs. It may even break something, but I'm not aware
of anything that depends on it explicitly.
Greg, do you know of anything in particular that depends on a kobjects not
being released before their
On Fri, 20 Apr 2007, Tejun Heo wrote:
> Hello, Alan.
>
> Alan Stern wrote:
> > This doesn't solve a related problem: a subsystem wants to register
> > devices and to provide a set of mutually-exclusive services to the
> > devices' drivers. The mutual exclusion has to be provided by a mutex or
>
On Fri, 20 Apr 2007 14:27:06 +0900,
Tejun Heo <[EMAIL PROTECTED]> wrote:
> Hello, Alan.
>
> Alan Stern wrote:
> > This doesn't solve a related problem: a subsystem wants to register
> > devices and to provide a set of mutually-exclusive services to the
> > devices' drivers. The mutual exclusion
On Thu, 19 Apr 2007 16:49:11 +0200,
Cornelia Huck <[EMAIL PROTECTED]> wrote:
> On Thu, 19 Apr 2007 10:20:51 -0400 (EDT),
> Alan Stern <[EMAIL PROTECTED]> wrote:
>
> > The patch below, applied on top of Cornelia's changes plus the
> > kobject_init() patch I posted earlier, actually seems to
Hello, Dmitry.
Dmitry Torokhov wrote:
> On 4/19/07, Cornelia Huck <[EMAIL PROTECTED]> wrote:
>> On Thu, 19 Apr 2007 09:13:43 -0400,
>> "Dmitry Torokhov" <[EMAIL PROTECTED]> wrote:
>>
>> > Because they are managed by 2 different entities. the struct device
>> > objects are managed by device core
Hello, Dmitry.
Dmitry Torokhov wrote:
On 4/19/07, Cornelia Huck [EMAIL PROTECTED] wrote:
On Thu, 19 Apr 2007 09:13:43 -0400,
Dmitry Torokhov [EMAIL PROTECTED] wrote:
Because they are managed by 2 different entities. the struct device
objects are managed by device core and driver-specific
On Thu, 19 Apr 2007 16:49:11 +0200,
Cornelia Huck [EMAIL PROTECTED] wrote:
On Thu, 19 Apr 2007 10:20:51 -0400 (EDT),
Alan Stern [EMAIL PROTECTED] wrote:
The patch below, applied on top of Cornelia's changes plus the
kobject_init() patch I posted earlier, actually seems to work. And it
On Fri, 20 Apr 2007 14:27:06 +0900,
Tejun Heo [EMAIL PROTECTED] wrote:
Hello, Alan.
Alan Stern wrote:
This doesn't solve a related problem: a subsystem wants to register
devices and to provide a set of mutually-exclusive services to the
devices' drivers. The mutual exclusion has to be
Here's a patch to do what I mentioned earlier. Not tested -- it may
expose some existing bugs. It may even break something, but I'm not aware
of anything that depends on it explicitly.
Greg, do you know of anything in particular that depends on a kobjects not
being released before their
On Fri, 20 Apr 2007, Tejun Heo wrote:
Hello, Alan.
Alan Stern wrote:
This doesn't solve a related problem: a subsystem wants to register
devices and to provide a set of mutually-exclusive services to the
devices' drivers. The mutual exclusion has to be provided by a mutex or
On 4/20/07, Alan Stern [EMAIL PROTECTED] wrote:
Dmitry, in thinking things over some more I realized there's going to be a
problem with the autosuspend support in USB. It has to do with the way a
driver needs to prevent (or block) suspends from occurring while it is
actively using a device.
On 4/19/07, Alan Stern [EMAIL PROTECTED] wrote:
Among the worst offenders are character devices. None of the subsystem
providers offering char device registration performs immediate detach --
they are a lot like sysfs used to be. (In fact, they probably _can't_
provide it since read() or
Hi Tejun,
On 4/20/07, Tejun Heo [EMAIL PROTECTED] wrote:
Hello, Dmitry.
Dmitry Torokhov wrote:
On 4/19/07, Cornelia Huck [EMAIL PROTECTED] wrote:
On Thu, 19 Apr 2007 09:13:43 -0400,
Dmitry Torokhov [EMAIL PROTECTED] wrote:
Because they are managed by 2 different entities. the struct
Hello, Dmitry.
Dmitry Torokhov wrote:
Many drivers (at least all the SCSI/IDE ones) consider struct device as
the base class of the devices those drivers implement. I don't think we
can just consider those drivers to be wrong.
I am not saying they are wrong I am just saying that driver
On 4/20/07, Tejun Heo [EMAIL PROTECTED] wrote:
Hello, Dmitry.
Dmitry Torokhov wrote:
Many drivers (at least all the SCSI/IDE ones) consider struct device as
the base class of the devices those drivers implement. I don't think we
can just consider those drivers to be wrong.
I am not saying
On Fri, Apr 20, 2007 at 11:40:39AM -0400, Alan Stern wrote:
Here's a patch to do what I mentioned earlier. Not tested -- it may
expose some existing bugs. It may even break something, but I'm not aware
of anything that depends on it explicitly.
Greg, do you know of anything in particular
Hello, Alan.
Alan Stern wrote:
> This doesn't solve a related problem: a subsystem wants to register
> devices and to provide a set of mutually-exclusive services to the
> devices' drivers. The mutual exclusion has to be provided by a mutex or
> something similar, and the drivers need a way to
On Thu, 19 Apr 2007, Dmitry Torokhov wrote:
> On 4/19/07, Alan Stern <[EMAIL PROTECTED]> wrote:
> > On Wed, 18 Apr 2007, Dmitry Torokhov wrote:
> >
> > > I am still do not understand why this is needed. Would it not be
> > > simplier just to use a reference to struct device instead of embedding
>
On 4/19/07, Alan Stern <[EMAIL PROTECTED]> wrote:
On Wed, 18 Apr 2007, Dmitry Torokhov wrote:
> I am still do not understand why this is needed. Would it not be
> simplier just to use a reference to struct device instead of embedding
> it in a larger structure if their lifetimes are different
On Wed, 18 Apr 2007, Dmitry Torokhov wrote:
> I am still do not understand why this is needed. Would it not be
> simplier just to use a reference to struct device instead of embedding
> it in a larger structure if their lifetimes are different and one does
> not have a subsystem that takes care
On Thu, 19 Apr 2007 10:20:51 -0400 (EDT),
Alan Stern <[EMAIL PROTECTED]> wrote:
> The patch below, applied on top of Cornelia's changes plus the
> kobject_init() patch I posted earlier, actually seems to work. And it
> prevents an oops which I was able to trigger without it.
Looks nice at
On Thu, 19 Apr 2007, Cornelia Huck wrote:
> On Thu, 19 Apr 2007 01:06:25 +0900,
> Tejun Heo <[EMAIL PROTECTED]> wrote:
>
> > Heh heh, I'm amazed it actually works. Agreed that the list walking
> > isn't pretty but adding completion to each kobject still feels like too
> > much of overhead just
On 4/19/07, Cornelia Huck <[EMAIL PROTECTED]> wrote:
On Thu, 19 Apr 2007 09:13:43 -0400,
"Dmitry Torokhov" <[EMAIL PROTECTED]> wrote:
> Because they are managed by 2 different entities. the struct device
> objects are managed by device core and driver-specific objects are
> managed by their
On Thu, 19 Apr 2007 09:13:43 -0400,
"Dmitry Torokhov" <[EMAIL PROTECTED]> wrote:
> Because they are managed by 2 different entities. the struct device
> objects are managed by device core and driver-specific objects are
> managed by their respective driver.
Not sure if I understand you here. My
On Thu, 19 Apr 2007 01:06:25 +0900,
Tejun Heo <[EMAIL PROTECTED]> wrote:
> Heh heh, I'm amazed it actually works. Agreed that the list walking
> isn't pretty but adding completion to each kobject still feels like too
> much of overhead just for release waiting. Any better ideas?
Not really.
On 4/19/07, Cornelia Huck <[EMAIL PROTECTED]> wrote:
On Wed, 18 Apr 2007 12:41:36 -0400,
"Dmitry Torokhov" <[EMAIL PROTECTED]> wrote:
> I am still do not understand why this is needed. Would it not be
> simplier just to use a reference to struct device instead of embedding
> it in a larger
On Wed, 18 Apr 2007 12:41:36 -0400,
"Dmitry Torokhov" <[EMAIL PROTECTED]> wrote:
> I am still do not understand why this is needed. Would it not be
> simplier just to use a reference to struct device instead of embedding
> it in a larger structure if their lifetimes are different and one does
>
On Wed, 18 Apr 2007 12:41:36 -0400,
Dmitry Torokhov [EMAIL PROTECTED] wrote:
I am still do not understand why this is needed. Would it not be
simplier just to use a reference to struct device instead of embedding
it in a larger structure if their lifetimes are different and one does
not have
On 4/19/07, Cornelia Huck [EMAIL PROTECTED] wrote:
On Wed, 18 Apr 2007 12:41:36 -0400,
Dmitry Torokhov [EMAIL PROTECTED] wrote:
I am still do not understand why this is needed. Would it not be
simplier just to use a reference to struct device instead of embedding
it in a larger structure if
On Thu, 19 Apr 2007 01:06:25 +0900,
Tejun Heo [EMAIL PROTECTED] wrote:
Heh heh, I'm amazed it actually works. Agreed that the list walking
isn't pretty but adding completion to each kobject still feels like too
much of overhead just for release waiting. Any better ideas?
Not really. But I'm
On Thu, 19 Apr 2007 09:13:43 -0400,
Dmitry Torokhov [EMAIL PROTECTED] wrote:
Because they are managed by 2 different entities. the struct device
objects are managed by device core and driver-specific objects are
managed by their respective driver.
Not sure if I understand you here. My view of
On Thu, 19 Apr 2007, Cornelia Huck wrote:
On Thu, 19 Apr 2007 01:06:25 +0900,
Tejun Heo [EMAIL PROTECTED] wrote:
Heh heh, I'm amazed it actually works. Agreed that the list walking
isn't pretty but adding completion to each kobject still feels like too
much of overhead just for release
On 4/19/07, Cornelia Huck [EMAIL PROTECTED] wrote:
On Thu, 19 Apr 2007 09:13:43 -0400,
Dmitry Torokhov [EMAIL PROTECTED] wrote:
Because they are managed by 2 different entities. the struct device
objects are managed by device core and driver-specific objects are
managed by their respective
On Thu, 19 Apr 2007 10:20:51 -0400 (EDT),
Alan Stern [EMAIL PROTECTED] wrote:
The patch below, applied on top of Cornelia's changes plus the
kobject_init() patch I posted earlier, actually seems to work. And it
prevents an oops which I was able to trigger without it.
Looks nice at first
On Wed, 18 Apr 2007, Dmitry Torokhov wrote:
I am still do not understand why this is needed. Would it not be
simplier just to use a reference to struct device instead of embedding
it in a larger structure if their lifetimes are different and one does
not have a subsystem that takes care of
On 4/19/07, Alan Stern [EMAIL PROTECTED] wrote:
On Wed, 18 Apr 2007, Dmitry Torokhov wrote:
I am still do not understand why this is needed. Would it not be
simplier just to use a reference to struct device instead of embedding
it in a larger structure if their lifetimes are different and
On Thu, 19 Apr 2007, Dmitry Torokhov wrote:
On 4/19/07, Alan Stern [EMAIL PROTECTED] wrote:
On Wed, 18 Apr 2007, Dmitry Torokhov wrote:
I am still do not understand why this is needed. Would it not be
simplier just to use a reference to struct device instead of embedding
it in a
Hello, Alan.
Alan Stern wrote:
This doesn't solve a related problem: a subsystem wants to register
devices and to provide a set of mutually-exclusive services to the
devices' drivers. The mutual exclusion has to be provided by a mutex or
something similar, and the drivers need a way to
On Thu, 19 Apr 2007, Tejun Heo wrote:
> More afterthoughts. If a mutex is used to protect access against
> removal. There is no reason to hold reference to it.
>
> kernel_thread()
> {
> /* wanna dereference my_obj */
> mutex_lock();
> verify my_obj is there and use it if so.
On 4/18/07, Tejun Heo <[EMAIL PROTECTED]> wrote:
Hello,
Alan Stern wrote:
> On Wed, 18 Apr 2007, Tejun Heo wrote:
>
>> Hello, all.
>>
>> Agreed with the problem but I'm not very enthusiastic for adding
>> kobj->owner. How about the following? exit() routines will have to
>> do
Hello,
Alan Stern wrote:
> On Thu, 19 Apr 2007, Tejun Heo wrote:
>
>> The goal of immediate-disconnect is to remove such lingering reference
>> counts so that device_unregister() or driver detach puts the last
>> reference count.
>
> Yes, I understand. If you had immediate-disconnect then you
On Thu, 19 Apr 2007, Tejun Heo wrote:
> The goal of immediate-disconnect is to remove such lingering reference
> counts so that device_unregister() or driver detach puts the last
> reference count.
Yes, I understand. If you had immediate-disconnect then you wouldn't need
Cornelia Huck wrote:
> On Wed, 18 Apr 2007 03:41:10 +0900,
> Tejun Heo <[EMAIL PROTECTED]> wrote:
>
>
>
> OK, I hit a bit on the code. Once I saved a reference to the completion
> in kobject_cleanup, it seemed to survive a load/unload testloop for a
> module registering a device. However, I
Tejun Heo wrote:
>> Incidentally, Tejun, I'm all in favor of a immediate-detach driver model
>> approach. Unfortunately it's impossible to realize fully, although we
>> could come much closer than we are now.
>>
>> Here's an example where immediate-detach cannot be implemented. A driver
>>
Hello,
Alan Stern wrote:
> On Wed, 18 Apr 2007, Tejun Heo wrote:
>
>> Hello, all.
>>
>> Agreed with the problem but I'm not very enthusiastic for adding
>> kobj->owner. How about the following? exit() routines will have to
>> do device_unregister_wait() instead of device_unregister(). On
On Wed, 18 Apr 2007 10:53:55 -0400 (EDT),
Alan Stern <[EMAIL PROTECTED]> wrote:
> Many drivers, especially those for hot-pluggable buses, register and
> unregister devices dynamically. These events can occur in time-critical
> situations, where the driver cannot afford to wait for all the
On Wed, 18 Apr 2007 03:41:10 +0900,
Tejun Heo <[EMAIL PROTECTED]> wrote:
OK, I hit a bit on the code. Once I saved a reference to the completion
in kobject_cleanup, it seemed to survive a load/unload testloop for a
module registering a device. However, I still dislike this "list of
waiters"
On Wed, 18 Apr 2007, Tejun Heo wrote:
> Hello, all.
>
> Agreed with the problem but I'm not very enthusiastic for adding
> kobj->owner. How about the following? exit() routines will have to
> do device_unregister_wait() instead of device_unregister(). On return
> from it, it's guaranteed that
Cornelia Huck wrote:
On Wed, 18 Apr 2007 17:46:09 +0900,
Tejun Heo <[EMAIL PROTECTED]> wrote:
It's debatable but I think things will be safer this way. If we wait by
default, we are forced to check that all references are dropped and will
have a stack dump indicating which object is causing
On Wed, 18 Apr 2007 17:46:09 +0900,
Tejun Heo <[EMAIL PROTECTED]> wrote:
> It's debatable but I think things will be safer this way. If we wait by
> default, we are forced to check that all references are dropped and will
> have a stack dump indicating which object is causing problem when
>
Cornelia Huck wrote:
> On Wed, 18 Apr 2007 03:49:01 +0900,
> Tejun Heo <[EMAIL PROTECTED]> wrote:
>
>> Oh, one more thing, with proper code audit, we can just make
>> device_unregister() do the waiting instead of adding separate
>> device_unregister_wait(). I think that will be a good step
Cornelia Huck wrote:
> On Wed, 18 Apr 2007 03:41:10 +0900,
> Tejun Heo <[EMAIL PROTECTED]> wrote:
>
>> Hello, all.
>>
>> Agreed with the problem but I'm not very enthusiastic for adding
>> kobj->owner. How about the following? exit() routines will have to
>> do device_unregister_wait() instead
On Wed, 18 Apr 2007 03:49:01 +0900,
Tejun Heo <[EMAIL PROTECTED]> wrote:
> Oh, one more thing, with proper code audit, we can just make
> device_unregister() do the waiting instead of adding separate
> device_unregister_wait(). I think that will be a good step toward
> immediate-detach driver
On Wed, 18 Apr 2007 03:41:10 +0900,
Tejun Heo <[EMAIL PROTECTED]> wrote:
> Hello, all.
>
> Agreed with the problem but I'm not very enthusiastic for adding
> kobj->owner. How about the following? exit() routines will have to
> do device_unregister_wait() instead of device_unregister(). On
On Wed, 18 Apr 2007 03:41:10 +0900,
Tejun Heo [EMAIL PROTECTED] wrote:
Hello, all.
Agreed with the problem but I'm not very enthusiastic for adding
kobj-owner. How about the following? exit() routines will have to
do device_unregister_wait() instead of device_unregister(). On return
On Wed, 18 Apr 2007 03:49:01 +0900,
Tejun Heo [EMAIL PROTECTED] wrote:
Oh, one more thing, with proper code audit, we can just make
device_unregister() do the waiting instead of adding separate
device_unregister_wait(). I think that will be a good step toward
immediate-detach driver model.
Cornelia Huck wrote:
On Wed, 18 Apr 2007 03:41:10 +0900,
Tejun Heo [EMAIL PROTECTED] wrote:
Hello, all.
Agreed with the problem but I'm not very enthusiastic for adding
kobj-owner. How about the following? exit() routines will have to
do device_unregister_wait() instead of
Cornelia Huck wrote:
On Wed, 18 Apr 2007 03:49:01 +0900,
Tejun Heo [EMAIL PROTECTED] wrote:
Oh, one more thing, with proper code audit, we can just make
device_unregister() do the waiting instead of adding separate
device_unregister_wait(). I think that will be a good step toward
On Wed, 18 Apr 2007 17:46:09 +0900,
Tejun Heo [EMAIL PROTECTED] wrote:
It's debatable but I think things will be safer this way. If we wait by
default, we are forced to check that all references are dropped and will
have a stack dump indicating which object is causing problem when
something
Cornelia Huck wrote:
On Wed, 18 Apr 2007 17:46:09 +0900,
Tejun Heo [EMAIL PROTECTED] wrote:
It's debatable but I think things will be safer this way. If we wait by
default, we are forced to check that all references are dropped and will
have a stack dump indicating which object is causing
On Wed, 18 Apr 2007, Tejun Heo wrote:
Hello, all.
Agreed with the problem but I'm not very enthusiastic for adding
kobj-owner. How about the following? exit() routines will have to
do device_unregister_wait() instead of device_unregister(). On return
from it, it's guaranteed that all
On Wed, 18 Apr 2007 03:41:10 +0900,
Tejun Heo [EMAIL PROTECTED] wrote:
patch
OK, I hit a bit on the code. Once I saved a reference to the completion
in kobject_cleanup, it seemed to survive a load/unload testloop for a
module registering a device. However, I still dislike this list of
waiters
On Wed, 18 Apr 2007 10:53:55 -0400 (EDT),
Alan Stern [EMAIL PROTECTED] wrote:
Many drivers, especially those for hot-pluggable buses, register and
unregister devices dynamically. These events can occur in time-critical
situations, where the driver cannot afford to wait for all the references
Hello,
Alan Stern wrote:
On Wed, 18 Apr 2007, Tejun Heo wrote:
Hello, all.
Agreed with the problem but I'm not very enthusiastic for adding
kobj-owner. How about the following? exit() routines will have to
do device_unregister_wait() instead of device_unregister(). On return
from it,
Tejun Heo wrote:
Incidentally, Tejun, I'm all in favor of a immediate-detach driver model
approach. Unfortunately it's impossible to realize fully, although we
could come much closer than we are now.
Here's an example where immediate-detach cannot be implemented. A driver
binds to a
Cornelia Huck wrote:
On Wed, 18 Apr 2007 03:41:10 +0900,
Tejun Heo [EMAIL PROTECTED] wrote:
patch
OK, I hit a bit on the code. Once I saved a reference to the completion
in kobject_cleanup, it seemed to survive a load/unload testloop for a
module registering a device. However, I still
1 - 100 of 106 matches
Mail list logo
