Updated the tooling to fetch the ioctl number used in the driver source code
and compare it to the one used in nvproxy. It is possible that ioctl numbers
change across driver versions (under our foot). It is imperative that we mimic
these changes in nvproxy. For example, in 575.57.08 driver release,
NV2080_CTRL_CMD_FB_QUERY_DRAM_ENCRYPTION_INFOROM_SUPPORT changed from
0x20801358 to 0x20801357.
To achieve this effect, the AST parser has been updated in the previous change
to be able to parse numerical constants. However, it is unable to parse macros
that evaluate to constants (trust me, I tried). So as a workaround, the
nvidia_driver_differ declares "const uint64_t" variables in the source file
which is created with all relevant includes (see parser.WriteIncludeFile()).
These variables are defined with name "GVISOR_{IOCTL_MACRO} = IOCTL_MACRO" so
they should not conflict with anything in the driver. Then we use the AST
parser to evaluate the value of the const variable and return that.
PiperOrigin-RevId: 793350829
The `driver_ast_parser` tool is now able to parse constants alongside with
structs. This is done by adding a new `constants` field in the JSON input, and
a `constants` field in the JSON output. This will be used later to detect
changes in constants between driver versions.
Also, the parser's `structs` argument was renamed to `input` to account for
both structs and constants.
PiperOrigin-RevId: 792677998
We have `SupportedStructTypes` which provides the same list of structs but
also includes their type.
This is also more performant, because TestStructDefinitionParity was calling
SupportedStructNames() and SupportedStructTypes(), which was doing duplicate
work of reconstructing the entire ABI twice.
This change also gets rid of TestSupportedStructNames. We are already testing
that in TestStructDefinitionParity. Should speed up tests as we don't have to
compile and analyze the driver source code twice for nvproxy_driver_parity_test
PiperOrigin-RevId: 789894363
