> Well, we may start returning -ENODEV when such event happens. > At the frontend, we could use fe->exit = DVB_FE_DEVICE_REMOVED to > signalize it. I don't think that the demod frontend has something > similar.
> Yet, it should be up to the userspace application to properly handle > the error codes and close the devices on fatal non-recovery errors like > ENODEV. > So, what we can do, at Kernel level, is to always return -ENODEV when > the device is known to be removed, and double check libdvbv5 if it > handles such error properly. well, we do not use libdvbv5, and -ENODEV can be returned by read syscall, but for poll syscall, -ENODEV can never be returned to user, as negative number is invalid type for poll returned value. please refer to my second patch. and in our usage, whether to read the device is up to the poll result. if tuner is plugged out, and there is no data in dvr ringbuffer. then user code will still go on polling the dvr device and never stop. if POLLERR is returned, then user will perform read dvr, and then -ENODEV can be got, and user will stop polling dvr device. the first patch is enough to fix the deadlock issue. the second patch is used to correct the wrong type of returned value. the third patch is used to provide user a better controlling logic.
