On Sat, Oct 13, 2012 at 3:33 AM, Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx> wrote: > Hi Luis, > > On Friday 12 October 2012 16:49:31 Luis R. Rodriguez wrote: >> From: "Luis R. Rodriguez" <mcgrof@xxxxxxxxxxxxxxxx> >> >> 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. 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? Would it be wrong to be explicit about using a UAPI header alone if no kernel API files exist? [0] https://backports.wiki.kernel.org/index.php/Documentation/compat [1] https://backports.wiki.kernel.org/ Luis _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
