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
