IIO (+ more general?) Error condition handling (e.g. wire fell out errors)
I'm not sure how general this is, hence sent to LKML and IIO.
Some of the devices we have can produce interrupts indicating that everything has gone horribly wrong. Sometimes this is also embedded in the main data stream.
The best examples are all the 'wonderful' ways the ad2s1210 resolver can go wrong. None of these would be expected to be part of normal operating conditions.
So, the question is - do we want these to go through our main events stream? They are weird and wonderful and often don't align well with our existing event codes. Loss of data error for example (a wire came out). Others could possibly be made to fit but that would loose some of the semantics. Loss of tracking could be a rate of change threshold event, but it really is meant to tell you the data could be garbage.
So three options come to mind:
1) Have a magic set of event codes for device class specific fault events and push through our main event path. For reference of non IIO types - that is an anon file descriptor obtained by an ioctl on the devices chrdev. Events are a simple timestamp / eventcode pair.
2) Add another anon file that you get via an ioctl as a separate event reporting channel. We then define a big list of error codes without aiming for any real structure. Drivers would then need to document what they can throw out (preferably under sysfs?)
3) Consider these out of band (from the out of band event data) and look at other options for reporting them.
Is there anything general out there for reporting hardware failures that would be appropriate? Sometime these conditions are the sort of thing that should cause a siren to go off.
They might be sensor failure.... or they might mean you have a runaway train heading for a station...
(p.s. I hope no one is using the current driver for trains, though that might explain British trains...)
Thanks,
Jonathan
Quoted 2 lines
3) Consider these out of band (from the out of band event data) and look at other options for reporting them.
Treat it like a socket/pipe perhaps - if it "goes down" then report it as having hung up and deliver a SIGPIPE or similar and with an appropriate error code for those catching it (-EIO ?)
That generally gets noticed.
Quoted 4 lines
Is there anything general out there for reporting hardware failures that would be appropriate? Sometime these conditions are the sort of thing that should cause a siren to go off.
They might be sensor failure
There are two things here - one is making sure the app notices (where we have equivalent handling in other interfaces) the other is what to do about it. We don't have a general framework for reporting system component failure. That's something that ought to get fixed generally to report everything from "that new nasty smell was formerly your hard disk" to a sensor fail.
Quoted 2 lines
(p.s. I hope no one is using the current driver for trains, though that might explain British trains...)
Tssh... there is Linux on UK trains, but it's usually driving annoying announcement/video systems.
Alan
Sorry for the slow reply!
Quoted 6 lines
Quoted 2 lines
3) Consider these out of band (from the out of band event data) and look at other options for reporting them.
Treat it like a socket/pipe perhaps - if it "goes down" then report it as having hung up and deliver a SIGPIPE or similar and with an appropriate error code for those catching it (
-EIO?)
I guess that will work. Feels a little clunky, but such is life.
Quoted 8 lines
That generally gets noticed.
Quoted 4 lines
Is there anything general out there for reporting hardware failures that would be appropriate? Sometime these conditions are the sort of thing that should cause a siren to go off.
They might be sensor failure
Quoted 6 lines
There are two things here - one is making sure the app notices (where we have equivalent handling in other interfaces) the other is what to do about it. We don't have a general framework for reporting system component failure. That's something that ought to get fixed generally to report everything from "that new nasty smell was formerly your hard disk" to a sensor fail.
It does seem like that would be useful.
Quoted 6 lines
Quoted 3 lines
(p.s. I hope no one is using the current driver for trains, though that might explain British trains...)
Tssh... there is Linux on UK trains, but it's usually driving annoying announcement/video systems.
:) Good thing their are no 'this runs Linux' badges on the speakers. I've nothing against them using Linux, just the driver in question which is currently 'interesting'.
Thanks,
Jonathan