I agree with the 2nd option proposed by Sakari since we need to develop the media controller-based gstreamer source element which depends on these header files.
BRs Xiaolin -----Original Message----- From: Sakari Ailus [mailto:[email protected]] Sent: Tuesday, December 21, 2010 23:16 To: Arjan van de Ven Cc: Teemu Tuominen; [email protected]; Laurent Pinchart; Zhang, Xiaolin; Wang, Wen W Subject: Re: [Meego-kernel] About kernel-headers package in Meego (V4L2 subdev/Media Controller) Hi Arjan and everyone else, Arjan van de Ven wrote: > On 12/5/2010 10:20 AM, Teemu Tuominen wrote: >> Ok, I see your point, however the derived products will have to >> structle with the issue anyhow. So, I would prefer a strict lining to >> follow the targets that will affect on userland architecture and the >> decisions what projects are selected into core. In some cases even if >> they are experimental - The Meego is. However, I'm not experienced at >> all in how such is handled in other distros and though ok with the flow. >> > > it's very simple: Get Your Interface Accepted By Linus. That's your way > out of the mess. > > Other distros do exactly the same thing.. in fact, MeeGo so far has been > much more liberal, in fact MUCH TOO liberal, in accepted interfaces that > haven't yet been accepted/released by Linus. > Try sending something like this to Red Hat or Novell. They'll laugh you > out of the room. After reading the whole thread, while I agree with your reasoning behind the policy on kernel-headers, we have a few issues with it. A little background below. Digital cameras, especially ones providing fine control for host software, have not been traditionally very well supported in regards to standardised interfaces in Linux. There's been just V4L2 which is good for what it's meant for but it doesn't cover everything, so we now have v4l2_subdev user space and MC interfaces in addition to that. As you know, the upstreaming is not complete yet. The interfaces used by digital cameras are difficult to standardise. The reason for this is that there are no standard digital cameras; the functionality of cameras varies a lot more than that of e.g. a serial port or a hard disk. Simple (relatively speaking) components like sensors have generalisable interfaces but more complex parts like ISPs have e.g. unique controls and use table data which are not found elsewhere in that exact format. This causes that the driver defines a part of its own user space API. The user programs using the driver must include the driver API header. The user space packages that depend on especially the driver dependent APIs are close to hardware and hardware dependent as well. I do not think that neither kind of APIs would be used by generic applications directly. Besides V4L2, MC and v4l2_subdev are generic but low level whereas the rest are hardware dependent. The user space packages depend on these headers to compile but the headers will not be usable from the vendor provided kernel. I think we have such situation at least on TI OMAP 3 (Nokia N900) and Intel Medfield based platforms. The goal, naturally, is that all this code must go to upstream. But that will take time, less for some, more for others. In the meantime, there are a few options, but I don't like very much either of them: - Make headers part of the source packages and include them locally. This is a very ugly hack. Every time a kernel header changes it has to be copied to each and every source package which uses it. Modifications may also be required to source code and / or Makefile(s). - Create new package for the changed (or new) platform kernel headers only. This was already suggested. I think this is definitely a better option than the above. (I'm not sure if RPM allows replacing files which are part of a different package.) Comments would be very welcome. -- Sakari Ailus [email protected] _______________________________________________ MeeGo-kernel mailing list [email protected] http://lists.meego.com/listinfo/meego-kernel
