Hi Luis,
On Saturday 13 October 2012 10:00:42 Luis R. Rodriguez wrote:
On Sat, Oct 13, 2012 at 3:33 AM, Laurent Pinchart wrote:
On Friday 12 October 2012 16:49:31 Luis R. Rodriguez wrote:
From: "Luis R. Rodriguez" mcgrof@do-not-panic.com
The UAPI changes split kernel API and userspace API content onto two separate header files. The userspace API drm content was moved to include/uapi/drm/ with the same file name while kernel specific API content was kept under include/drm/ with the same file name. When one file was split into two files the kernel header includes the uapi header and a UAPI prefix was added to the uapi header for its header guard. When there was no kernel API content found the uapi header file was the only one that was kept and the original guard for the header file was kept. In this particular case the original users of this header file were not modified and the uapi header file is expected to be picked up by path.
This may work well at compilation on the kernel but when backporting this creates a few complexities.
Could you please provide more details about those complexities ?
Sure, the backported DRM code is as-is code from linux-next. The header search path includes a copy of a few select header files from linux-next, the rest are part of the compat [0] project to help with backporting and the last set are from your own kernel. In this particular case the UAPI effort pushed into include/uapi/drm a few files which are now no longer present in the old include/drm/ location when there was no respective kernel-only APIs exposed. For DRM code that did not use the new uapi/drm/ path for old header includes this means that upon backporting the older kernel's header file would be used obviously leading to a series of compilation failures. By being explicit about the path, as was done with a few other header files, we can suck out DRM code intact from the kernel to be compilable for older kernels. As of the v3.7-rc1 the compat-drivers project [1] will be providing DRM modules. The new UAPI changes broke compilation on compat-drivers when compiling DRM code so to fix this we either patch code taken from the Linux kernel as I have done, force inclusion of a few specific headers files, or use include_next tricks. It turns out that forcing inclusion of -I$(M)/include/uapi as a path search prior to your own kernel's at compilation time did not help.
Shouldn't that be added as a search path *after* include/linux/ instead of before ?
The include_next trick can work as well but that'd mean synching the UAPI files regularly into compat. I'd much prefer to have code intact when possible when backporting so the option I stuck with then was to patch the code directly and then as part of compat-drivers to always copy that day's linux-next UAPI headers into the current directory for compilation. I see no other driver code using the uapi path explicitly though, is that by design?
As far as I understand that's by design, yes. Kernel code isn't expected to reference uapi/ headers directly.
Would it be wrong to be explicit about using a UAPI header alone if no kernel API files exist?
I personally don't really like including such "features" in a mainline just for backporting, especially when they go against the spirit of the architecture (the uapi/ split design principles in this case). The way we're dealing with this in the V4L backport tree (http://git.linuxtv.org/media_build.git) is to play with Makefiles, include compatibility headers and, if nothing else can work, maintain backport patches for mainline code.
[0] https://backports.wiki.kernel.org/index.php/Documentation/compat [1] https://backports.wiki.kernel.org/