On Sun, 7 Nov 2004 21:40:58 +0100
Oliver Neukum <[EMAIL PROTECTED]> wrote:
> Am Sonntag, 7. November 2004 22:41 schrieb Luca Risolia:
> > > Is it used within a kernel thread?
> > > If not, any signal can arrive at any time through the kill syscall.
> >
> > I meant to say "cirmustances" by "context": in these cases, if a signal has
> > arrived, the proper behaviour of the low-level driver is to let the upper
> > layer
> > of the kernel (videodev) handle the event. For this reason, the driver
> > returns
> > "err" (-ERESTARTSYS) to the caller.
>
> Yes, but why do you change the device status? The arrival of a signal
> has no connection with the device.
Not with the device, strictly speaking, but is does have connection with
the device driver and the way the things are implemented: the signal might
arrive before the handler can turn and set the STREAM_OFF; in this case,
videodev might retry to call the same ioctl(cmd), causing possible race
conditions with the running completion_handler(). Apart from handling "real"
hardware problems as well, DEV_MISCONFIGURED covers this situation.
When DEV_MISCONFIGURED is set, the user application is forced to close() the
device so that the re-initialization and reconfiguration can be performed on
next open(), becouse close() is also what normally happens with commonly used
signals, like SIGHTERM or SIGHKILL, when the device "does not respond".
I don't think this policy hurts, no more than a non-interruptible
wait_event_timeout() or locking mechanisms on the stream status at least.
Regards,
Luca Risolia
-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
