Hello,
The new kbuild architecture included as part of Linux 2.5 has a number of
problems that I would consider 2.5 show-stoppers and which must be resolved.
I believe the issues listed below are all regressions from 2.4; some are
easier to fix than others.
All of the issues relate to the building of kernel modules external to the
kernel source tree. Using kbuild to construct kernel modules instead of using
Makefile "hacks" has been rasied by the kbuild developers repeatedly on this
list and is, I believe, the preferred way to do it.
In my opinion, for kbuild to be a viable method of constructing kernel
modules external to the shipped source tree, the following conditions must
be met:
o The state of kbuild in shipped (distribution) kernels must be such that the
construction of external modules can be done without having to modify the
shipped kernel-source package.
This can be seen in almost all of today's distributions. Generally, you find
that the kernel-source package ships with a .config and the tree has had make
dep done. Effectively, the kernel source package matches the installed
binary. In the case of kbuild 2.4, this is excellent, as kbuild is in a ready
state to compile external modules against this kernel-source tree, and
perhaps more importantly, against the running kernel.
However, in 2.5, conditions are different depending on whether you are
building against a CONFIG_MODVERSIONS kernel or not. The preparation of the
tree in either case is also more complicated, though this does not seem
unreasonable.
I have determined that the kernel tree must have the following things done to
it before modules can be built against it (without modification to the tree).
make mrproper # ensure tree is completely tidied
cp -a /etc/kernelops-2.5 .config # copy of your default config
make oldconfig # configure tree to work with this config
So far, this matches the behaviour in 2.4. However, in 2.4 you need only do a
"make dep" (and, I believe, some distros also touch a couple of other files).
kbuild 2.4 is now ready to build kernel modules against the running kernel,
irrespective of kernel configuration. Module symbol CRCs are computed as
demanded by CONFIG_MODVERSIONS, so this is not a problem under 2.4.
In 2.5, I determined that the steps below were required instead of make dep.
make prepare # builds supporting utilities, links asm
# directory, creates vermagic.h and version.h
make scripts # seems to be required, not sure why (should
# already be called by prepare, right?)
This tree now seems prepared to build external modules against it, as the
headers are now complete and the compile-time utilities are built. When
CONFIG_MODVERSIONS is set, this even builds genksyms for us.
So far, so good. In fact, just doing this much allows traditional Makefile
"hacks" like NVIDIA's driver Makefile to build quite happily against this
tree. However, trying to use kbuild 2.5 now presents the following problems:
/bin/sh: line 1: .tmp_version/foo.mod: Permission denied
And later:
/bin/sh: line 1: ./.__modpost.cmd: Permission denied
These issues are *only* apparent when you attempt to build external modules
as an unprivileged user. Building as the user owning the source tree (in
distributions, I'd imagine this is ordinarily user "src" or "rpm" or even
"root", in certain cases) causes no such errors.
o KBUILD 2.5 creates temporary files inside the kernel source tree.
- .__modpost.cmd is hardcoded by Makefile and cannot be redirected;
- .tmp_version seems also to be hardcoded, but I am not sure.
- there is no obvious (or documented) way to manipulate the $srctree or
$objtree variables.
Doing a simple:
$ mkdir -p .tmp_versions;
$ touch .__modpost.cmd
$ chmod 1777 .tmp_versions .__modpost.cmd
Allows me to build external modules against a kernel tree as an unprivileged
user. I only need read-access to the tree.
Again, under 2.4, kbuild does not require such hacks. It does not seem to
create ANY temporary files in the source tree and works fine for building as
a non-privileged user.
The second major issue is that under 2.4, CONFIG_MODVERSIONS did not require
vmlinux to have been built in order to generate symbol CRCs. Building driver
foo against a kbuild 2.4 tree can even utilise modversions, simply by
including modversions.h.
Under 2.5, considerable improvements to the module system has made it so that
CONFIG_MODVERSIONS can only be utilised by modules in or out of the kernel
tree after vmlinux has been constructed. In the kbuild output I clearly see:
scripts/modpost vmlinux <list of all modules> /blah/dir/here/foo.o
Which correctly adds the required symbol CRCs to the module. A quick look at
scripts/modpost.c shows me that int modversions is not set to 1 unless
vmlinux is passed into it. Indeed, this makes sense, but it does mean that if
I build driver foo against an uncompiled kernel tree (as ordinarily would be
shipped by a distribution), the resulting driver does not have symbol CRCs
added to it, as was the case in 2.4.
To summarise, for kbuild 2.5 to be a viable platform for building external
modules in distribution kernels, the following improvements must be made:
o If it is considered important that users should be able to compile kernel
drivers (not install them) as an unprivileged user, the tree must desist
from creating temporary files and directories in the $srctree. Instead, the
utilisation of /tmp where suitable would be better;
o If distribution trees are to be shipped with CONFIG_MODVERSIONS set, kbuild
2.5 needs to have some way other than vmlinux of providing symbol CRCs. I
certainly am not sufficiently versed in the intricacies of the new module
system to comment on a solution, but I'm sure somebody here is.
As a developer, these concerns do not affect me at all. A portable kbuild
solution surpasses the inherent inflexibility of Makefile hacks and I can
already use it with moderate success on 2.4 and 2.5 platforms, as I always
build and install all modules as root, and always have a vmlinux hanging
around.
I do not use a linux "distribution", but I appreciate that the end user
typically will, and ultimately these kbuild solutions will be utilised by the
end user, for building both fully free drivers and proprietary kits including
kernel glue (e.g., the NVIDIA driver).
As some of you may be aware, I have been working with Christian Zander for
some time now, maintaining the NVIDIA driver (through UNOFFICIAL patches)
against the linux 2.5 mainline. Recently I rewrote NVIDIA's Makefile to use
kbuild on 2.4 and 2.5, and with the exception of the noted issues, it seems
to work properly for the majority of people. You can see these patches at
http://minion.de/ , Christian's site.
For your convenience, I have attached a sample Makefile which could easily be
adapted to be the module foo I have mentioned. In reality, this is a Makefile
for the proprietary NVIDIA module, although I am sure sensible people will
appreciate the global ramifications of these issues and how they will affect
the building of any module, free or non-free.
I'm open to suggestions if there are solutions or workarounds I have not
considered. If there are, however, it might be sensible to document these.
Cheers,
Alistair Strachan.
This archive was generated by hypermail 2b29 : Tue Jul 15 2003 - 22:00:40 EST