Re: [Haifux] Telling the kernel business is closed (my weekly riddle)
Thanks. And indeed, I don't use ioctl()s as of yet. All in all, I filled the code with ugly if (catastrophe) return -EIO; (more or less) and got the desired effect: Applications complain about I/O Error, which is at least not misleading. Eli Shachar Shemesh wrote: On 28/06/11 19:54, Nadav Har'El wrote: For ioctl(2), I don't know what to use - the manual page doesn't list EIO; Perhaps your ioctl(2) can return the failure announcement as part of its normal return value, and don't fail the actual ioctl? IOCTL are not documented, as they cannot be documented. This is an open interface between specific user space program and specific kernel code, and anything goes there. I don't think that's what Eli was aiming for, however. Shachar ___ Haifux mailing list Haifux@haifux.org http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux
Re: [Haifux] Telling the kernel business is closed (my weekly riddle)
On 27/06/11 00:29, Eli Billauer wrote: The brute-force way to do this is to check a device-global flag every invocation of read(), write(), and other relevant methods. Maybe also before returning a successful value. If the flag is set ( = problem detected) return some -EDROPDEAD, so that application software reacts, and maybe someone will go to /var/log/messages to get a better idea of what happened. (I think I'll settle for -ENODEV) Nobody expects ENODEV on an already opened device. I'd go for EIO, myself. So here comes my question: Is there a convention for how a device driver can tell the kernel that certain devices (as in /dev/something) have turned unusable, in particular when some of them are already open? I guess this is related to hotpluggable devices, but in the latter case I suppose it's the kernel informing the device driver about the event, and not vice versa. I don't think you need to do anything beyond that, unless the situation is recoverable without a reboot (say - by sending a reset to the chip). If that's the case, I'd reset the chip, return EIO to any connection opened before the reset, and treat new connection like I always would. Of course, if there is a way for you to make the old connections still function, even better. Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com ___ Haifux mailing list Haifux@haifux.org http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux
Re: [Haifux] Telling the kernel business is closed (my weekly riddle)
Shachar Shemesh wrote: Nobody expects ENODEV on an already opened device. I'd go for EIO, myself. And so shall I. Thanks. As for how to handle the disaster event, my question was if there's a standard way to handle it. Checking if the device is OK all the time will make the code uglier. And the truth is that I don't care about recovering from such an error. If it ever happens, I want the user to trash the hardware or change the kernel configuration to avoid ASPM (a form of power management). The chip sometimes fails to wake up correctly from short power downs, and data is lost. It's basically as severe as discovering that the RAM may not perform writes every now and then. Not something I want to work around. So here comes my question: Is there a convention for how a device driver can tell the kernel that certain devices (as in /dev/something) have turned unusable, in particular when some of them are already open? I guess this is related to hotpluggable devices, but in the latter case I suppose it's the kernel informing the device driver about the event, and not vice versa. I don't think you need to do anything beyond that, unless the situation is recoverable without a reboot (say - by sending a reset to the chip). If that's the case, I'd reset the chip, return EIO to any connection opened before the reset, and treat new connection like I always would. Of course, if there is a way for you to make the old connections still function, even better. Shachar Eli ___ Haifux mailing list Haifux@haifux.org http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux
Re: [Haifux] Telling the kernel business is closed (my weekly riddle)
On 27/06/11 11:31, Eli Billauer wrote: Checking if the device is OK all the time will make the code uglier. GIGO it is, then. Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com ___ Haifux mailing list Haifux@haifux.org http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux
Re: [Haifux] Telling the kernel business is closed (my weekly riddle)
On Monday, 27 בJune 2011 11:31:48 Eli Billauer wrote: Shachar Shemesh wrote: Nobody expects ENODEV on an already opened device. I'd go for EIO, myself. And so shall I. Thanks. ... And the truth is that I don't care about recovering from such an error. Another strategy is to throw SIGPIPE at the relevant processes: * Con: it is usually expected upon write(2) not read(2) et-al. * Pros: - At least for write(2) the semantics is natural -- no more writes on this file descriptor. - Kills the offending process by default. - Process may catch it in a signal handler (easy to write some global cleanup + exit code) Cheers, -- Oron Peled Voice: +972-4-8228492 o...@actcom.co.il http://users.actcom.co.il/~oron Lottery: A tax on people who are bad at math. ___ Haifux mailing list Haifux@haifux.org http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux
