Weekly Edition
Return to the Kernel page
| |||||||||||||
Separating kernel source and object files
The build process in recent 2.6 kernels allows for the separation of source
and object trees. If a kernel build is started with the O=
option, the resulting object files (and other built files) will go into the
directory specified, rather than being mixed in with the source. Some
developers find this way of doing things easier to manage, especially if
the same source tree is being used to build kernels for multiple
architectures or with multiple sets of configuration options.
One distributor (SUSE) has begun shipping kernels which have been built in this manner. The difference has gone unnoticed by almost all users, but one vendor of proprietary modules recently posted a strong message accusing SUSE of forking the kernel. The specific issue is that this vendor's modules would no longer build with SUSE's kernels, and that problem turned out to be a result of the separated source and object trees. When a kernel's modules are installed under /lib, a symbolic link called build is made pointing to the source tree. This link is used by the external module build process to find kernel headers, configuration files, and needed object files. When SUSE adopted the separate object directory, it redirected the build link to point to that directory, rather than to the original source. That is, after all, where many of the necessary files will be found. Unfortunately for this particular vendor, their modules needed some other files which are only found in the source tree. When the build link was directed elsewhere, those modules would no longer compile. The fix was relatively straightforward, but this situation forced a new discussion on how the build system should work when separate object directories are in use. The result is a new patch from Sam Ravnborg which nails down how these links should work. With this patch (not merged as of this writing), the build link would always point to the object directory. Doing things this way allows most external modules to continue to build without changes. A new link (source) will be added to point to the source directory when needed. And a small, special-purpose makefile is placed in the object directory; its job is to bridge the gap between the two trees and make most external module builds work with no changes required. (Log in to post comments)
dear me Posted Jun 24, 2004 5:03 UTC (Thu) by mbp (subscriber, #2737) [Link] What a silly silly troll.
Separating kernel source and object files Posted Jun 24, 2004 20:23 UTC (Thu) by Baylink (subscriber, #755) [Link] I don't know if it's a 'troll'. but clearly the 4front guy expended political capitalunnecessarily in his characterization of what's going on. I, personally, am not entirely happy with SuSE 9's architectural decisions on a couple of topis as well; most notably that initscripts in init.d are mixed in with other things in that directory; RedHat's approach to this is much cleaner and clearer and easier to manipulate. But I don't go around waving a loaded gun about my distaste...
forking Posted Jun 25, 2004 17:37 UTC (Fri) by giraffedata (subscriber, #1954) [Link] This guy really has no understanding of how open source works.First of all, it's not a fork unless you stop including new work from the original stream. Second, it's perfectly normal for a Linux distribution to have its own variation on the Linux kernel. It's the way open source is meant to be. Finally, the false advertising claim: It is incorrect for Suse to call its kernel Linux 2.6.5 -- that name is already taken by Linus' tree. But I don't think Suse calls it that. I think it calls it "2.6.5 based," which is certainly true, and adds additional version information to the name. 4Front Technologies is apparently learning the hard way why so many companies build products only for Windows -- there's only one variation of it to worry about.
forking Posted Jun 26, 2004 0:38 UTC (Sat) by EricBackus (guest, #2816) [Link] > 4Front Technologies is apparently learning the hard> way why so many companies build products only for > Windows -- there's only one variation of it to worry about. You've apparently never managed a large project on Windows. There are a zillion variations to worry about - Win98/ME/2k/XP (and they're different depending on whether they were clean installed or updated from a previous version), various service packs and updates, lots of different versions of IE, amount of RAM, free disk space... Making a large project robust on Windows takes significant work. The real reason so many companies only build products for Windows is that they think essentially all of their potential customers run Windows. Which sometimes may even be true.
forking Posted Jul 2, 2004 15:06 UTC (Fri) by forthy (guest, #1525) [Link] uname -r gives something like "2.6.4-54.3-default" (depends on updates),so it's based on kernel 2.6.4, and the 54.3's build. You can see the patches they applied in the source RPM, since SuSE always ships an unpatched source tar file, and a patch. This is how everyone does it, and I'm clearly fine with this approach. For SuSE not being compatible with other kernels, or requiring special build options or whatever, that's why it is Open Source. SuSE has the freedom to do that: we want them to do that. After all, SuSE e.g. helped to get Alsa stable by providing 2.4 kernels with Alsa for a long time, when Linus didn't.
|
|||||||||||||