Em Thu, 17 Dec 2015 14:55:11 +0100 Arnd Bergmann <arnd@xxxxxxxx> escreveu: > On Thursday 17 December 2015 10:45:56 Mauro Carvalho Chehab wrote: > > If I understood well, he's proposing to do is: > > > > struct media_v2_topology { > > __u64 topology_version; > > > > __u32 num_entities; > > __u32 num_interfaces; > > __u32 num_pads; > > __u32 num_links; > > > > __u64 ptr_entities; > > __u64 ptr_interfaces; > > __u64 ptr_pads; > > __u64 ptr_links; > > }; > > > > The problem is that, if we latter need to extend it to add a new type > > the extension will not be too nice. For example, I did some experimental > > patches adding graph groups: > > > > Can you clarify how the 'topology_version' is used here? Is that > the version of the structure layout that decides how we interpret the > rest, or is it a number that is runtime dependent? No, topology_version is just a mononotonic counter that starts on 0 and it is incremented every time a graph object is added or removed. It is meant to be used to track if the topology changes after a previous call to this ioctl. On existing media controller embedded device hardware, it should always be zero, but on devices that allow dynamic hardware changes (some embedded DTV hardware allows that - also on devices with FPGA, with RISC CPUs or hot-pluggable devices) should use it to know if the hardware got modified. This is also needed on multi-function devices where different drivers are used for each function. That's the case of au0828, with uses a media driver for video, and the standard USB Audio Class driver for audio. As the drivers are independent, the topology_version will be zero when the first driver is loaded, but it will change during at probe time on second driver. It will also be increased if one of the drivers got unbind. > If this is an API version, I think the answer can simply be to drop > the topology_version field entirely, and use a new ioctl command code > whenever the API changes. This is the preferred method anyway. Regards, Mauro. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html