Closed be32826 closed 7 months ago
I don't think this is the right approach.
The parser here provides an error because osi_linux
requires that field as part of its profile. If you simply bypass the error you'll generate invalid profiles (i.e. osi_linux
can't start up with them).
A better approach would be to see how this field contributes to osi_linux
logic, ensure it handles the case that it is not present, and then mark this field optional (e.g. as with start_time
example) and change the corresponding script to handle that.
Perhaps there's some middle ground? It might be nice to have the config-generator support creating partial configs when fields are unavailable instead of having to patch it every time we want to make something optional? Perhaps a warning being generated along the lines of Field X is missing - this may cause an error with OSI Linux
. Or maybe a flag like --skip-missing
that turns these errors into a warning?
Then, to fix #1422 we'll need to update OSI Linux itself to work without this information.
I have a patch for fixing osi_linux
with newer kernels and I will make a PR soon, but this change is one part of the fix. If we aren't going to merge this, should I put everything in one PR, or is there a better way to have optional fields with kernelinfo_gdb?
Fixes part of #1422. If a struct field is deleted, kernelinfo_gdb will do the best it can instead of erroring and outputting nothing. Higher-level plugins that need to get a list of threads and need to be compatible with newer kernels can implement their own handling on top of this.