Hi Mauro, On Thursday 26 May 2011 01:34:10 Mauro Carvalho Chehab wrote: > 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. Issues arise when devices have floating point registers. And yes, that happens, I've learnt today about an I2C sensor with floating point registers (in this specific case it should probably be put in the broken design category, but it exists :-)). > > 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. I'm inclined to agree with you, but we should address these issues now, while we have relatively few devices impacted by them. I fear that ignoring the problem and hoping it will go away by itself will bring us to a difficult position in the future. We should show the industry in which direction we would like it to go. -- Regards, Laurent Pinchart -- 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
