Re: trying out usb hotplugs

[Takashi Iwai <tiwai@suse.de>]

At Fri, 29 Nov 2002 12:24:50 +0100 (CET),
Jaroslav wrote:
> 
> On Fri, 29 Nov 2002, Takashi Iwai wrote:
> 
> > At Fri, 29 Nov 2002 10:39:22 +0100 (CET),
> > Jaroslav wrote:
> > > 
> > > On Fri, 29 Nov 2002, Takashi Iwai wrote:
> > > 
> > > > At Fri, 29 Nov 2002 08:52:43 +0100 (MET),
> > > > Clemens Ladisch wrote:
> > > > > 
> > > > > Takashi Iwai wrote:
> > > > > > Martin Langer wrote:
> > > > > > > usb hotplug works perfect if my usbmidi client isn't aconnected to another
> > > > > > > midi client. But the aconnected usb midi device still remains in the clients
> > > > > > > list, after hotpluging out.
> > > > > >
> > > > > > yep,  when the connection exists, the connected devices (on both
> > > > > > sides) are regarded as active.
> > > > > 
> > > > > The sequencer design allows asynchronous removal of clients.
> > > > 
> > > > yes, but this may still try to send some bytes to the unplugged
> > > > rawmidi device at the disconnection.  i'll change rawmidi code to
> > > > ignore that.
> > > 
> > > Well, I'm trying to solve these "hotplug" problems. Unfortunately, it 
> > > seems difficult to detect, if another task is in the middle of our 
> > > callback. I think that we'll end up using mutexes.
> > 
> > hmm, but mutex costs too much even for non-pluggable devices...
> > 
> > in the case of rawmidi and oss-mixer, we can put "disconnected" flag
> > and ignore the access if the flag is on at the rawmidi and oss-mixer
> > routines, so that the control doesn't reach to low-level functions.
> 
> Well, but if you check this flag at the beginning, then you don't know, if
> hardware is away in the middle of operation. The point is, that we have
> to finish the last operation and clean structures "when no task is
> inside".

yes.  the unplugging may happen at any time, since it's a physical
action and cannot be locked by a kernel :)
this means, the invalid access in the middle of the code cannot be
avoided by a program code unless all function is atomic.
thus, the low-level stuff should take it into account if the card is
pluggable, anyway, for example, avoiding a possible infinte loop,
etc.

in the case of usb, the real critical part depends on the usb core and
controller routine.  i hope it's ok.

the "disconnection-check-and-ignore" method is not perfect, but, if
the low level stuff doesn't go crazy even at the disconnected state,
the result wouldn't be so critical.


btw, the oss-emulation problem seems to be on the different point.
the oss-emulation accesses directly to the records without taking any
reference counters.  thus snd_*_can_unregister() passes the check even
the control (or pcm) files are still open.
i'll keep on debugging this.


Takashi


-------------------------------------------------------
This SF.net email is sponsored by: Get the new Palm Tungsten T 
handheld. Power & Color in a compact size! 
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en