On Mon, 16 Apr 2007, Greg KH wrote:
> > > I've got a module which registers a struct device. (It represents a
> > > virtual device, not a real one, but that doesn't matter.)
>
> Wait, that's the issue right there.
>
> Don't do that.
>
> devices should be created by busses or the platform
On Mon, 16 Apr 2007 15:12:47 -0700,
Greg KH <[EMAIL PROTECTED]> wrote:
> Ah, just found this original thread, now Cornelia's patches make more
> sense...
I would have included a pointer, but couldn't access marc yesterday
evening, sorry...
>
> On Fri, Apr 13, 2007 at 11:24:58AM -0400, Alan
On Mon, 16 Apr 2007 15:12:47 -0700,
Greg KH [EMAIL PROTECTED] wrote:
Ah, just found this original thread, now Cornelia's patches make more
sense...
I would have included a pointer, but couldn't access marc yesterday
evening, sorry...
On Fri, Apr 13, 2007 at 11:24:58AM -0400, Alan Stern
On Mon, 16 Apr 2007, Greg KH wrote:
I've got a module which registers a struct device. (It represents a
virtual device, not a real one, but that doesn't matter.)
Wait, that's the issue right there.
Don't do that.
devices should be created by busses or the platform core, which owns
Ah, just found this original thread, now Cornelia's patches make more
sense...
On Fri, Apr 13, 2007 at 11:24:58AM -0400, Alan Stern wrote:
> Tejun, it just occurred to me that you would be interested in this email
> thread. Just to bring you up to speed, here's the original question:
>
> >
On Mon, 16 Apr 2007 10:43:01 -0400 (EDT),
Alan Stern <[EMAIL PROTECTED]> wrote:
> Actually it has to be done in kobject_init() since the release method can
> be called any time after that, even if the kobject is never add'ed.
True. This would also imply that we only ever must free a kobject
Alan Stern wrote:
On the other hand, this proposal involves adding a fair amount of overhead
(all those .owner fields) for a rather small benefit. And it involves
modifying a core kernel subsystem (kernel/module.c). All to prevent
certain unlikely sorts of errors when removing a module --
On Mon, 16 Apr 2007, Cornelia Huck wrote:
> On Fri, 13 Apr 2007 11:24:58 -0400 (EDT),
> Alan Stern <[EMAIL PROTECTED]> wrote:
>
> > I have to admit, this is a puzzler. I'm beginning to think there should
> > be two types of module references: Those which (like module dependency)
> > will
On Fri, 13 Apr 2007 11:24:58 -0400 (EDT),
Alan Stern <[EMAIL PROTECTED]> wrote:
> I have to admit, this is a puzzler. I'm beginning to think there should
> be two types of module references: Those which (like module dependency)
> will prevent rmmod from running, and those which (like the one
On Fri, 13 Apr 2007 11:24:58 -0400 (EDT),
Alan Stern [EMAIL PROTECTED] wrote:
I have to admit, this is a puzzler. I'm beginning to think there should
be two types of module references: Those which (like module dependency)
will prevent rmmod from running, and those which (like the one here)
On Mon, 16 Apr 2007, Cornelia Huck wrote:
On Fri, 13 Apr 2007 11:24:58 -0400 (EDT),
Alan Stern [EMAIL PROTECTED] wrote:
I have to admit, this is a puzzler. I'm beginning to think there should
be two types of module references: Those which (like module dependency)
will prevent rmmod
Alan Stern wrote:
On the other hand, this proposal involves adding a fair amount of overhead
(all those .owner fields) for a rather small benefit. And it involves
modifying a core kernel subsystem (kernel/module.c). All to prevent
certain unlikely sorts of errors when removing a module --
On Mon, 16 Apr 2007 10:43:01 -0400 (EDT),
Alan Stern [EMAIL PROTECTED] wrote:
Actually it has to be done in kobject_init() since the release method can
be called any time after that, even if the kobject is never add'ed.
True. This would also imply that we only ever must free a kobject with
Ah, just found this original thread, now Cornelia's patches make more
sense...
On Fri, Apr 13, 2007 at 11:24:58AM -0400, Alan Stern wrote:
Tejun, it just occurred to me that you would be interested in this email
thread. Just to bring you up to speed, here's the original question:
I've got
Tejun, it just occurred to me that you would be interested in this email
thread. Just to bring you up to speed, here's the original question:
> I've got a module which registers a struct device. (It represents a
> virtual device, not a real one, but that doesn't matter.) Obviously the
>
On Fri, 13 Apr 2007 16:15:18 +0200,
"Markus Rechberger" <[EMAIL PROTECTED]> wrote:
> most dvb usb drivers call the device node unregistration when a device
> gets unplugged (when
> At this time the filehandle can still be open, the patch on that site
> sets a flag that disallows
> any further
Cornelia Huck wrote:
On Fri, 13 Apr 2007 13:42:04 +0200,
"Markus Rechberger" <[EMAIL PROTECTED]> wrote:
seems like you have the same problem as the dvb framework has/had.
http://mcentral.de/hg/~mrec/v4l-dvb-stable
The last 3 changesets do the trick to not oops, it will delay the
On Fri, 13 Apr 2007 13:42:04 +0200,
"Markus Rechberger" <[EMAIL PROTECTED]> wrote:
> seems like you have the same problem as the dvb framework has/had.
>
> http://mcentral.de/hg/~mrec/v4l-dvb-stable
>
> The last 3 changesets do the trick to not oops, it will delay the
> deinitialization of the
Alan,
seems like you have the same problem as the dvb framework has/had.
http://mcentral.de/hg/~mrec/v4l-dvb-stable
The last 3 changesets do the trick to not oops, it will delay the
deinitialization of the device till the last user closed the device node.
Markus
Cornelia Huck wrote:
On
On Thu, 12 Apr 2007 17:23:18 -0400 (EDT),
Alan Stern <[EMAIL PROTECTED]> wrote:
> Here's a not-so-theoretical question.
>
> I've got a module which registers a struct device. (It represents a
> virtual device, not a real one, but that doesn't matter.) Obviously the
> module's exit routine has
On Thu, 12 Apr 2007 17:23:18 -0400 (EDT),
Alan Stern [EMAIL PROTECTED] wrote:
Here's a not-so-theoretical question.
I've got a module which registers a struct device. (It represents a
virtual device, not a real one, but that doesn't matter.) Obviously the
module's exit routine has to wait
Alan,
seems like you have the same problem as the dvb framework has/had.
http://mcentral.de/hg/~mrec/v4l-dvb-stable
The last 3 changesets do the trick to not oops, it will delay the
deinitialization of the device till the last user closed the device node.
Markus
Cornelia Huck wrote:
On
On Fri, 13 Apr 2007 13:42:04 +0200,
Markus Rechberger [EMAIL PROTECTED] wrote:
seems like you have the same problem as the dvb framework has/had.
http://mcentral.de/hg/~mrec/v4l-dvb-stable
The last 3 changesets do the trick to not oops, it will delay the
deinitialization of the device
Cornelia Huck wrote:
On Fri, 13 Apr 2007 13:42:04 +0200,
Markus Rechberger [EMAIL PROTECTED] wrote:
seems like you have the same problem as the dvb framework has/had.
http://mcentral.de/hg/~mrec/v4l-dvb-stable
The last 3 changesets do the trick to not oops, it will delay the
On Fri, 13 Apr 2007 16:15:18 +0200,
Markus Rechberger [EMAIL PROTECTED] wrote:
most dvb usb drivers call the device node unregistration when a device
gets unplugged (when
At this time the filehandle can still be open, the patch on that site
sets a flag that disallows
any further access to
Tejun, it just occurred to me that you would be interested in this email
thread. Just to bring you up to speed, here's the original question:
I've got a module which registers a struct device. (It represents a
virtual device, not a real one, but that doesn't matter.) Obviously the
module's
Here's a not-so-theoretical question.
I've got a module which registers a struct device. (It represents a
virtual device, not a real one, but that doesn't matter.) Obviously the
module's exit routine has to wait until the release() routine for that
device has been invoked -- if it returned too
Here's a not-so-theoretical question.
I've got a module which registers a struct device. (It represents a
virtual device, not a real one, but that doesn't matter.) Obviously the
module's exit routine has to wait until the release() routine for that
device has been invoked -- if it returned too
28 matches
Mail list logo
