summaryrefslogtreecommitdiff
path: root/include/android/hardware/libhardware
diff options
context:
space:
mode:
authorPaul Elder <paul.elder@ideasonboard.com>2021-05-27 14:10:25 +0900
committerPaul Elder <paul.elder@ideasonboard.com>2021-06-01 18:52:05 +0900
commitae7419869adf7c619865e06e13250be88a76b413 (patch)
tree30b030f02b59023a23a6f96f0f60e7d27a40242e /include/android/hardware/libhardware
parenta931188e1de2c7663ff6c516141eb714c2a5dd8e (diff)
utils: ipc: mojo: Error if ControlInfoMap/List doesn't prefix libcamera
The mojo parser is fine if there are types that are used in array/map members that it does not know about. These are usually caught by the C++ compiler, because the generated code refers to unknown types. This feature is necessary for us for supporting FrameBuffer::Plane as an array/map member, since as long as the type has an IPADataSerializer and the struct defined in C++, the generated code will run fine (FrameBuffer::Plane is not defined anywhere in mojom but is used as an array member in IPABuffer). The types that are defined in controls.h (or any header included in ipa_interface.h) will all be compiled by the C++ compiler fine, since the generated files all include controls.h. The types that are there that are not ControlInfoMap or ControlList (like ControlValue) will still fail at the linker stage. For example: struct A { array<ControlValue> a; }; will compile fine, but will fail to link, since IPADataSerializer<ControlValue> doesn't exist. This behavior, although not the best, is acceptable. The issue is that if ControlInfoMap or ControlList are used as array/map members without the libcamera prefix, the compiler will not complain, as the types are valid, and the linker will also not complain, as IPADataSerializer<ControlList> and IPADataSerializer<ControlInfoMap> both exist. However, the code generator will not recognize them as types that require a ControlSerializer (since mojo doesn't recognize them, so they are different from the ones that it does recognize with the libcamera namespace), and so the ControlSerializer will not be passed to the serializer in the generated code. This is the cause of the FATAL breakage: FATAL IPADataSerializer ipa_data_serializer.cpp:437 ControlSerializer not provided for serialization of ControlInfoMap Since ControlInfoMap and ControlList are the only types that will run into this issue, we solve this by simply detecting if they are used without the prefix, and produce an error at that point in the code generator. As the code generator stage no longer has information on the source code file and line, we output the struct name in which the error was found (ninja will output the file name). Signed-off-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Diffstat (limited to 'include/android/hardware/libhardware')
0 files changed, 0 insertions, 0 deletions