sg3_utils
sg3_utils copied to clipboard
hreinecke
Machine parseable output
We use the amazing sg_ses command line tools to get information from various Element Types like Array device slot and Device slot and slurp out interesting (to us) attributes like the SAS address and device slot number and if the physical disk is blinking (i.e. Ident=0|1) .
But I need to aggregate this information on a routine basis - so I'm ashamed to say I've grown a rather robust parser to massage the textual output of these tools into a more predictable data exchange format.
I feel like a missed a more obviously correct solution though. The information reported by these tools isn't really line oriented - it's structured! Is there a machine parsable output format - or a really obvious way to wrap some high level interface in the underlying c library from a dynamic scripting language and get all the same data that's normally displayed in the textual output - but in a more structured form? Like a giant json blob or even a single huge struct with descriptive field names?
Any feedback or insight on how you might approach a problem space like this would be well received! My apologies if I missed something obvious! Thanks in advance.
Perhaps! Full disclosure, it wouldn't be a full-time project for me and my C tends to be CPython wrappers these days - so I may miss some idiomatic bits. But if you'd be willing to review it and help me get it into a shape you'd be willing to maintain - I'd be interested if I could help with any grunt work?!
It would be a huge kick in the pants if you could point me roughly towards the module(s) that gather the various pieces of information for display and any outline for what you think would be appropriate testing (how does one maintain parity between the human and machine oriented outputs?).
Thanks for your consideration!
The output from the various sg3-utils is designed to be human readable first and foremost. My thinking was if you wanted to machine parse it that you would dump the response in hex (typically the -H option) then parse it from there. Now while parsing that hex might be simple for an INQUIRY response and some log, mode and VPD pages, when you get to something like SES and the complex interaction between several diagnostic pages, then that parsing becomes a real headache. [Well writing that C code gave me plenty of headaches.] With the sg_ses utility the --inner-hex option was meant to help in cutting the amount of hex to the data carrying parts. Not sure that option will make things any easier for machine parsing the output. Perhaps the output from --inner-hex could be worked on to aid machine parsing.
