headers
Ben Woodard | 30 Mar 2001 18:41
Picon
Favicon

event not supported.

When I pull the usb connection, I get this message in my logs:

Mar 30 08:07:01 localhost /etc/hotplug/usb.agent: USB remove event not supported

What are the issues associated with it. Is this something that just
hasn't been coded up or is it something that can't be coded up.

If it simply hasn't been written, if you give me a few pointers on how
it should be written. I'll code it up.

-ben
Permalink | Reply | 15 comments |
headers
David Brownell | 30 Mar 2001 19:21

Re: (remove) event not supported.

> Mar 30 08:07:01 localhost /etc/hotplug/usb.agent: USB remove event not supported
> 
> What are the issues associated with it. Is this something that just
> hasn't been coded up or is it something that can't be coded up.

Awkward to code up.  What one really wants to happen is have
the device's module removed ... and _maybe_ some driver-specific
action (not that I can think of any examples just now).  But:

- the dynamic linking framework doesn't track how many devices
  are attached to each driver module ... so if there's another device
  controlled by the same driver, but it's not opened, removing that
  module would be incorrect.  ("module use count" doesn't cover
  uses, just opens.)

- nothing's tracking which modules are used with which device,
  and if the device is gone you can't query it to find that out!

Such issues aren't specific to USB; any hotpluggable bus has such
problems.  But it's worst for USB:  PCMCIA and Cardbus
tend to only have one device of a type at a time, and typically
only have two slots, but USB can handle a hundred devices,
and it's not that uncommon to have multiple devices.

> If it simply hasn't been written, if you give me a few pointers on how
> it should be written. I'll code it up.

I think that it'll be tough to provide a "good" fix for this without
updating the module framework; and that maybe a few other
issues will show up too.  But maybe there are better ways to
(Continue reading)

Permalink | Reply | 14 comments |
headers
Brad Hards | 31 Mar 2001 14:57
Picon

Re: (remove) event not supported.

David Brownell wrote:
> 
> > Mar 30 08:07:01 localhost /etc/hotplug/usb.agent: USB remove event not supported
> >
> > What are the issues associated with it. Is this something that just
> > hasn't been coded up or is it something that can't be coded up.
> 
> Awkward to code up.  What one really wants to happen is have
> the device's module removed ... and _maybe_ some driver-specific
> action (not that I can think of any examples just now).  But:
umounting a storage device? Or does that happen automatically? I am
not going to pull out a mounted zip drive to find out...

> - the dynamic linking framework doesn't track how many devices
>   are attached to each driver module ... so if there's another device
>   controlled by the same driver, but it's not opened, removing that
>   module would be incorrect.  ("module use count" doesn't cover
>   uses, just opens.)
This could be trivially extended to have a inc_dev_open_count() and
inc_dev_use_count(), where the use count get incremented in probe()
and the open count gets incremented in open(). Naturally you also
have to have a dec version of each as well, in disconnect() and 
close().

> - nothing's tracking which modules are used with which device,
>   and if the device is gone you can't query it to find that out!
maybe the driver could have a list of devices? not so easy to 
implement though.

Brad
(Continue reading)

Permalink | Reply | 13 comments |
headers
David Brownell | 31 Mar 2001 17:02

Re: (remove) event not supported.

> > > Mar 30 08:07:01 localhost /etc/hotplug/usb.agent:
> > >     USB remove event not supported
> > >
> > > What are the issues associated with it. Is this something that just
> > > hasn't been coded up or is it something that can't be coded up.
> > 
> > Awkward to code up.  What one really wants to happen is have
> > the device's module removed ... and _maybe_ some driver-specific
> > action (not that I can think of any examples just now).  But:
>
> umounting a storage device? Or does that happen automatically? I am
> not going to pull out a mounted zip drive to find out...

There we go, the example I knew was lurking!  Likewise shutting
down printer queues.

> > - the dynamic linking framework doesn't track how many devices
> >   are attached to each driver module ... so if there's another device
> >   controlled by the same driver, but it's not opened, removing that
> >   module would be incorrect.  ("module use count" doesn't cover
> >   uses, just opens.)
>
> This could be trivially extended to have a inc_dev_open_count() and
> inc_dev_use_count(), where the use count get incremented in probe()
> and the open count gets incremented in open(). Naturally you also
> have to have a dec version of each as well, in disconnect() and 
> close().

I'd hate to change the semantics of the "use" count (which is really
used as "open" count) ... but yes, adding another "driver count"
(Continue reading)

Permalink | Reply | 4 comments |
headers
Keith Owens | 31 Mar 2001 17:49
Picon

Re: (remove) event not supported.

On Sat, 31 Mar 2001 07:02:42 -0800, 
David Brownell <david-b <at> pacbell.net> wrote:
>I'd hate to change the semantics of the "use" count (which is really
>used as "open" count)

No, the module use count is a reference count on the module, not an
open count.  It correlates with the open count for many modules because
it is usually incremented in the open() routine, but it can be
incremented in any module function.  Any code assuming that mod use
count is the same as open files is broken.
Permalink | Reply | 3 comments |
headers
David Brownell | 31 Mar 2001 18:05

Re: (remove) event not supported.

> >I'd hate to change the semantics of the "use" count (which is really
> >used as "open" count)
> 
> No, the module use count is a reference count on the module, not an
> open count. 

It's not a reference count, since it doesn't address the case where
another module references it ... "rmmod" uses additional magic
to handle such dependency cases.  Since the counter can be (as
you highlighted!) updated at any time, there's nothing to make it
be a "reference" count.  The networking framework is pretty explicit
that it must be used as an "open" count (SET_MODULE_OWNER
arranges this).

Perhaps the best way to describe this counter is that it's there,
and "rmmod" won't remove modules where it's nonzero.  (Or
has never been nonzero...)  Which doesn't seem to accomodate
the needs of a hotplug-oriented world.

- Dave
Permalink | Reply | 2 comments |
headers
Keith Owens | 31 Mar 2001 18:18
Picon

Re: (remove) event not supported.

On Sat, 31 Mar 2001 08:05:18 -0800, 
David Brownell <david-b <at> pacbell.net> wrote:
>It's not a reference count, since it doesn't address the case where
>another module references it

It is a dynamic reference count.  The reference from another module is
a static reference count.  Historical.

>Since the counter can be (as
>you highlighted!) updated at any time, there's nothing to make it
>be a "reference" count.  The networking framework is pretty explicit
>that it must be used as an "open" count

If networking framework says that then it is wrong.

>(SET_MODULE_OWNER arranges this).

SET_MODULE_OWNER only exports the address of the module structure so
external code can adjust the use count.  Normally that is via the open
routine, but file systems just do one MOD_INC_USE_COUNT in fs/super.c
so it is a mount count, not an open count.  Some netfilter modules want
to count the number of packets controlled by that module, again not an
open count.
Permalink | Reply | 1 comment |
headers
David Brownell | 31 Mar 2001 18:52

Re: (remove) event not supported.

> >It's not a reference count, since it doesn't address the case where
> >another module references it
> 
> It is a dynamic reference count.  The reference from another module is
> a static reference count.  Historical.

I see what you're saying, but that doesn't mean I'd then agree
to call it a "reference" count!

> >Since the counter can be (as
> >you highlighted!) updated at any time, there's nothing to make it
> >be a "reference" count.

> >      The networking framework is pretty explicit
> >that it must be used as an "open" count
> 
> If networking framework says that then it is wrong.
> 
> >(SET_MODULE_OWNER arranges this).
> 
> SET_MODULE_OWNER only exports the address of the module structure so
> external code can adjust the use count. 

When the interface is opened or closed ... and a few other
cases related to calling into the module.  (Related point:  I
suspect the USB code should do the same when it probes
drivers, to avoid those same races.)

>From the perspective of a normal user, "lsmod" for net
drivers shows use count 0 when no interface exposed
(Continue reading)

Permalink | Reply | 0 comments |
headers
Keith Owens | 31 Mar 2001 04:03
Picon

Re: (remove) event not supported.

On Sat, 31 Mar 2001 22:57:18 +1000, 
Brad Hards <bhards <at> bigpond.net.au> wrote:
>David Brownell wrote:
>> - the dynamic linking framework doesn't track how many devices
>>   are attached to each driver module ... so if there's another device
>>   controlled by the same driver, but it's not opened, removing that
>>   module would be incorrect.  ("module use count" doesn't cover
>>   uses, just opens.)
>This could be trivially extended to have a inc_dev_open_count() and
>inc_dev_use_count(), where the use count get incremented in probe()
>and the open count gets incremented in open(). Naturally you also
>have to have a dec version of each as well, in disconnect() and 
>close().

AFAICT there is no need for another count, you can do MOD_INC_USE_COUNT
in any module function.  The use count does not have to be for just
open.  Add MOD_INC_USE_COUNT to the probe() function for each new
device.
Permalink | Reply | 7 comments |
headers
David Hinds | 31 Mar 2001 05:48
Favicon

Re: (remove) event not supported.

On Fri, Mar 30, 2001 at 06:03:32PM -0800, Keith Owens wrote:
> 
> AFAICT there is no need for another count, you can do MOD_INC_USE_COUNT
> in any module function.  The use count does not have to be for just
> open.  Add MOD_INC_USE_COUNT to the probe() function for each new
> device.

So what if I want to unload a module for a device that still exists?
These counts are also used in this way for non-hot-plugged devices.

For PCMCIA, device counts for each driver are published in
/proc/bus/pccard/drivers, and cardmgr uses this information to help
decide when to unload drivers.

-- Dave
Permalink | Reply | 5 comments |

Gmane