> > > > So in practice disconnect() means a cold, hard stop using that
> > > > device.
> > >
> > > Is that really to be expected?
> > >
> > > How often do admins change device drivers? In 99% of the cases, there's
> > > only one device driver.
> >
> > The same is true for configuration changes. Anyway the point is moot.
> > It's a legal operation. Therefore it has to work.
>
> You mean changing the configuration on a device?
Both. Changing configuration, as well as a disconnect() by ioctl.
> Right now there is no policy whatsoever about how that is supposed to
> work safely.
By not handling it in the kernel, for 2.4 you have to disconnect all drivers
through usbfs before you change configuration. For 2.5 I've made a
patch. I'd appreciate you taking a look at it. :-)
But I cannot see a way you could handle this without disconnecting
(or suspending in some cases) for the duration of the change.
> As a result, I think it's premature to say that it's moot and has to
> work. That may be true in the end, but I think we need to figure out all
> of the rest of the issues before we set anything in stone.
There already is a case where this is the requirement. Disconnect()
through ioctl. We may change it, but as things stand now, this
is it.
> Did you have a proposal for a contract about changing configurations?
Yes, a configuration change is:
1. Lock device
2. Disconnect all interfaces
3. Send control message
4. Unlock device
5. Probe all the device's interfaces
To a driver changing a configuration is an unplug, replug cycle.
> > > However, in the cases that I can see using a reference past
> > > disconnect(), an application still has a device open. In that case, the
> > > module usage count is already > 0, preventing module unloading.
> >
> > Entirely possible. But not guaranteed.
>
> I don't quite understand your comment,
An elevated module usage is nice and well, but beside the point.
Usage counts help against things being freed, but that's not the real
problem. You cannot transfer ownership by reference count.
That's what disconnect() does. It forcibly takes ownership of a device
away from a driver.
That you cannot , indeed must not, do IO to a device you don't own
is IMO fundamental. The question is where and how this is to be
achieved. Either a device driver or usbcore must make sure of that.
If this is to be done through reference counting, usbcore must ensure
that no inappropriate IO gets through. A simple reference count on a
data structure associated with a device cannot do that because
ownership of that device can be transfered. For the same reason
a simple flag for disconnected state will not work in all cases.
Usbcore would need a data structure for the linkage between a driver
and a device which could be declared broken and reference counted and
_all_ API calls connected with IO would need to be called with a reference
to this data structure.
The question of module usage count is connected to this question only
so far as you must not unload a driver still holding a reference.
But the issue is still there if modules are not used.
Regards
Oliver
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
