Re: (remove) event not supported.

Re: (remove) event not supported.

[David Brownell]

> 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
look at this problem.

- Dave




_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: (remove) event not supported.

[Brad Hards]

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

_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: (remove) event not supported.

[Keith Owens]

On Sat, 31 Mar 2001 22:57:18 +1000, 
Brad Hards <bhards@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.


_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: (remove) event not supported.

[Brad Hards]

Keith Owens wrote:
> 
> On Sat, 31 Mar 2001 22:57:18 +1000,
> Brad Hards <bhards@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.
An excellent point. I shouldn't write before the first cup of Russian
Caravan
in the morning.
Has anyone audited the drivers to see how consistently this is done?

Brad

_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: (remove) event not supported.

[David Hinds]

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

_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: (remove) event not supported.

[Brad Hards]

David Hinds wrote:
> 
> 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.
Also a good point, but in general, you don't want to do this. If there
is a device still "connected" to the system, you don't want to remove
the driver. For development, you might like to simulate a disconnection,
but the normal approach is that you want support for every device that is
connected to the system. Why remove a module for a device you are using?

It might be appropriate to remove the module (simulating the disconnect)
on some other basis, like that it is close()'d, but I am not sure exactly
what makes sense here.

Brad

_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: (remove) event not supported.

[David Brownell]

> > 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.

It's important to have the same policy for MOD_INC_USE_COUNT
in all drivers.  Including drivers, like network drivers, where the use
count updating is automated ... both for hotpluggable drivers, and for
the other kind.


> 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.

I suppose USB could add a third field to /proc/bus/usb/drivers;
and PCI could add a /proc/bus/pci/drivers file too.  It'd work.

Maybe those could be argued as 2.4 features; but going that way
doesn't seem like the right general direction.  It's clearly a generic
facility that all hotpluggable drivers need, which in my book means
it's best to do it only once.

- Dave



_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: (remove) event not supported.

[David Brownell]

> > > 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"
is conceptually straightforward.  Packaging it (and documenting it)
would likely be a 2.5 issue.


> > - 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.

Most such drivers DO have a list of devices, but I shudder to think
of updating each one to publish it in some idiosyncratic format
somewhere in /proc ... best to fix this just once, for all drivers.

- Dave



_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: (remove) event not supported.

[Keith Owens]

On Sat, 31 Mar 2001 07:02:42 -0800, 
David Brownell <david-b@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.


_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: (remove) event not supported.

[David Brownell]

> >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




_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: (remove) event not supported.

[Keith Owens]

On Sat, 31 Mar 2001 08:05:18 -0800, 
David Brownell <david-b@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.


_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: (remove) event not supported.

[David Brownell]

> >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
by that driver is "up" (open).


>     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.

I'd argue those are all logically equivalent to "open":  dynamic
behavior (as you noted) that needs to prevent "rmmod".

One hopes that opening a block device like /dev/sda1 with
a user mode tool, rather than "mount", will prevent "rmmod"...

- Dave



_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: (remove) event not supported.

[David Hinds]

On Sun, Apr 01, 2001 at 06:53:01AM +1000, Brad Hards wrote:

> Also a good point, but in general, you don't want to do this. If there
> is a device still "connected" to the system, you don't want to remove
> the driver. For development, you might like to simulate a disconnection,
> but the normal approach is that you want support for every device that is
> connected to the system. Why remove a module for a device you are using?

Why?

Well the capability was one of the original reasons for creating
modules in the first place; they were not created for dynamic loading
of drivers for hot plug devices.

It is not an issue of removing a module for a device you are using;
you may want to remove a module for a device you are *not* using,
whether or not that device still happens to be present (and it may not
even be capable of removal).

-- dave

_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: (remove) event not supported.

[David Hinds]

On Sat, Mar 31, 2001 at 06:56:28AM -0800, David Brownell wrote:

> Maybe those could be argued as 2.4 features; but going that way
> doesn't seem like the right general direction.  It's clearly a generic
> facility that all hotpluggable drivers need, which in my book means
> it's best to do it only once.

I argued this too but Linus has said he believes it should be a bus
specific thing, rather than part of the generic hot plug facility.

-- Dave

_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: (remove) event not supported.

[Douglas Gilbert]

David Brownell <david-b@pacbell.net> wrote:

> I'd argue those are all logically equivalent to "open":  dynamic
> behavior (as you noted) that needs to prevent "rmmod".
>
> One hopes that opening a block device like /dev/sda1 with
> a user mode tool, rather than "mount", will prevent "rmmod"...
Yes.

Opening /dev/sda1 increases the usage count on the sd_mod.o
module and the associated lower level adapter driver (e.g.
aic7xxx.o). The SCSI mid-level (if it is a module) has its
usage count bumped when any lower level adapter driver
(e.g. aic7xxx.o) or upper level driver (sd_mod.o) registers 
itself.

Seen from the sd driver's POV, both mount and dd cause
sd_open() to be called and thus have the same affect
on usage counts.

Doug Gilbert

_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: (remove) event not supported.

[Trond Eivind Glomsrød]

David Hinds <dhinds@sonic.net> writes:

> On Sun, Apr 01, 2001 at 06:53:01AM +1000, Brad Hards wrote:
> 
> > Also a good point, but in general, you don't want to do this. If there
> > is a device still "connected" to the system, you don't want to remove
> > the driver. For development, you might like to simulate a disconnection,
> > but the normal approach is that you want support for every device that is
> > connected to the system. Why remove a module for a device you are using?
> 
> Why?
> 
> Well the capability was one of the original reasons for creating
> modules in the first place; they were not created for dynamic loading
> of drivers for hot plug devices.

What's cool about modules, is that you can support everything from the
same sets of bootdisk or the same kernel: Compare that to the state of
Slackware in 1995. Being able to add support by modules is important,
unloading them to save a few kilobytes much less so.

-- 
Trond Eivind Glomsrød
Red Hat, Inc.

_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel