Am Sonntag, 18. April 2004 16:36 schrieb Alan Stern:
> On Sat, 17 Apr 2004, Oliver Neukum wrote:
> > Am Samstag, 17. April 2004 22:13 schrieb Alan Stern:
> > > This sounds familiar... How long has it been that people have been
> > > busy replacing coarse locks like BKL with finer-grained locks?
> >
> > A spinlock could replace it. But that is a small detail.
>
> Yes it could. Then the driver would start to resemble its original form
> again, defeating Greg's point.
Where's the difference between
lock_kernel();
vs.
spin_lock(&skel_open_lock);
> > > Also, I notice that this code does indeed continue to communicate with
> > > the device after disconnect() returns.
> >
> > I see no way fixing that preserving the elegance of the design.
>
> Are you the same Oliver who always claims that correctness is more
> important than style? If not, what have you done with him? :-)
I am the same. I just have the decency to shoot the cow cleanly
instead of dismembering it ;-)
That is to say, let's shelve it for 2.7.
> > > > The key to make reference counting work, seems to be reallocating
> > > > the data structure operations are based on.
> > >
> > > Another key aspect is performing disconnect-type operations in two
> > > steps: receive the disconnect notification and sometime afterwards
> > > acknowledge completion of the disconnect by reducing a reference count.
> >
> > Yes, and not reusing the data structure in between.
>
> No, no! That's the whole point. The reference counting in the driver
> model is based on the idea that you send a notification to a driver
> telling it to stop using something, but it's allowed to continue using (or
> trying to use) it until it notifies you back. That's why we have both
> device_del() and a release() callback, for example.
Sorry. Maybe that's a linguistic problem. Let me be clearer.
Reference counting controls deallocation. In addition there's a state where
the connection between data structure and device is severed, meaning that
all io to it will cleanly fail. So far with me?
By "not reusing" I meant that there must be no way from the 'undead' state
back to functional. Once a data structure is in that state the reference
counter cannot be increased and the connection will never be reestablished.
If the physical device is still present a new data structure must be allocated.
> > > The problem is that physical USB devices aren't data structures -- you
> > > can't deallocate one and then allocate a new copy when you need it!
> > > Some form of synchronization is needed if we want to prevent multiple
> > > drivers from talking to the same interface at the same time.
> >
> > Nothing prevents giving out 'struct usb_endpoint_binding's which URBs
> > could be addressed to. They could have proper reference counting.
> > You could have them on lists which you walk in case of disconnect(),
> > config change, etc ...
>
> That is just what David has proposed for 2.7. We should give some extra
> thought to the problem of dealing with ep 0, however.
David is right. It seems to me that there's a problem with ep0 only if
we do reference counting on some internal representation of the device.
That would only shift the problem. We should actually allocate a data
structure with every binding which can be refcounted and io addressed to.
Regards
Oliver
-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
