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 _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
