Em 25-05-2011 20:20, Laurent Pinchart escreveu: > Hi Mauro, > > Thanks for applying the patches. For the record, the compromise was to > implement XU controls filtering to make sure that userspace applications won't > have access to potentially dangerous controls, and to push vendors to properly > document their XUs. Ok, thanks! >>> Some XU controls are variable-size binary chunks of data. We can't expose >>> that as V4L2 controls, which is why I expose them using a documented UVC >>> API. >> >> The V4L2 API allows string controls. > > Hans was very much against using string controls to pass raw binary data. Pass raw binary data is bad when we know nothing about what's passing there. A "firmware update" control-type however, is a different thing, as we really don't care about what's there. Yet, I agree that this may not be the best way of doing it. >>> Why would there be no applications using it ? The UVC H.264 XUs are >>> documented in the above spec, so application can use them. >> >> The Linux kernel were designed to abstract hardware differences. We should >> not move this task to userspace. > > I agree in principle, but we will have to rethink this at some point in the > future. I don't think it will always be possible to handle all hardware > abstractions in the kernel. Some hardware require floating point operations in > their drivers for instance. I talked with Linus some years ago about float point ops in Kernel. He said he was not against that, but there are some issues, as float point processors are arch-dependent, and kernel doesn't save FP registers. So, if a driver really needs to use it, extra care should be taken. That's said, some drivers use fixed point operations for some specific usages. > There's an industry trend there, and we need to think about solutions now > otherwise we will be left without any way forward when too many devices will > be impossible to support from kernelspace (OMAP4 is a good example there, some > device drivers require communication with other cores, and the communication > API is implemented in userspace). Needing to go to userspace to allow inter-core communication seems very bad. I seriously doubt that this is a trend. It seems more like a broken-by-design type of architecture. 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
