Hi, Nvidia ebuild uses kmod functions, which is being removed from the tree. i've converted it to kernel-mod.eclass
Created attachment 42339 [details] nvidia-kernel-1.0.6111-r2.ebuild I only compile-tested it, as I have no nvidia.
Created attachment 42340 [details, diff] nvidia.diff
kernel-mod eclass does not set the variable KV_OUTPUT, nor does it provide a similar variable, as far as I have been able to ascertain. This is the reason I have not changed the nvidia ebuilds allready. Without the KV_OUTPUT or equivelent variable, people using koutput kernels (ie building the kernel modules outside of /usr/src/linux (or wherever you keep your sources) just wont work. If someone can justify why this feature (which is part of nvidia's package now) should not be used fine, but until then I would prefer to see kernel-mod and kmod merged to keep said support available. (Im not asking for justification on removing kmod, im asking why we shouldnt use the ability provided in nvidias package to build the kernel module outside of /usr/src/linux).
Maybe Pete can comment on that.
Because we do not need this ability on kernels > 2.6.6. If you see people still using the old version please tell them to upgrade.
What? The koutput stuff never got introduced support wise until 2.6.6! So how can the support _not_ be needed in > 2.6.6
The 2.6.6 release introduced a fix to the build system where you can specify output directories, and as such, external module builds do not require write access to /usr/src/linux (if passed with the right params). I believe thats one of the main reasons that config-kernel/koutput is no longer supported and kmod is being removed - the problem that we tried to solve no longer exists.
Allright after going back through gentoo-dev and finding the mail about this... We need to 1) change SUBDIRS to M in Makefile.kbuild 2) change SYSOUT="${KV_OUTPUT}" to SYSOUT="${S}" 3) apply the changes in the diff here We should only do (1) for >= 2.6.6 kernels, and we should do the .ko / .o checking for 2.5 kernels aswell. Stefan I know you think people should be made to upgrade, but im not going to put something in the tree that isnt totally fool proof, it will support 2.4, 2.5 and 2.6 kernels.
Created attachment 42495 [details, diff] nvidia.diff We do not support 2.5 kernels and 2.6 kernels < 2.6.6. And we do not need to, as they have security problems.
Created attachment 42496 [details] nvidia-kernel-1.0.6111-r2.ebuild
OK that new patch is much better, but there still is one 2.6.5 kernel in the tree, so we WILL be supporting them, until such time as it is removed. Yes people should upgrade, especially those using 2.5 kernels, but im not going to just because im lazy and wont put one if statement in the ebuild. Donnie : Im going to commit this and a few other changes this afternoon, I'll make 6111 stable at the same time.
The if statement won't resolve problems for people using 2.5.* or <2.6.6 kernels. There was a problem in the build system, where even if you fed it a valid SUBDIRS= parameter, it still writes stuff into /usr/src/linux (this is not currently an issue in the kmod ebuild because we call addwrite). 2.6.6 introduced a fix, where *all* writing is now done in the directory supplied in SUBDIRS. This pretty much removed the need for kmod. At the same time, they renamed the SUBDIRS variable to M, and although SUBDIRS still works (as well as M), SUBDIRS may well be removed from the build system soon. Does this make sense now?
Its called dieing and telling them to disable sandbox (or preferably upgrade). Its what we did when 2.6.6 was first released and the support for M= was introduced. I didnt like it then, I dont now .. well not really .. Actually maybe it should just die, and tell them to upgrade (like at the moment it doesnt do anything to deal with the issue, it will simply fail for no apparent reason with sandbox, or some undefined symbol error).
Both this and original nvidia-kernel-1.0.6111-r2 ebuild are broken when using O= kernel option. I'm using kernel 2.6.9-cko2, but 2.6.9 is broken too.
Why do you need O=?
I don't need it actually, it just seemed like an elegant way to keep kernel sources and object files separate. Yes, I know distclean will remove them without any problem. With O= it is possible to update different kernel configs (add patches) without recompiling most everything, for say e.g. different archs. Well, nvidia-kernel works only on two, but other packages may support more. KV_OUTPUT isn't detected properly in kmod.eclass and required one tiny modification to enable overriding of that variable.
> KV_OUTPUT isn't detected properly in kmod.eclass and required one tiny > modification to enable overriding of that variable. Well its important that we support O=. What is the modification? Actually come to think of it, kmod.eclass has nothing to do with M=, kmod.eclass as it is currently being used in the ebuild is required only to determine where the built objects and headers are, in the system.
The diff: --- eclass/kmod.eclass 2004-06-25 03:13:00.000000000 +0200 +++ eclass/kmod.eclass.new 2004-10-26 22:02:37.329487952 +0200 @@ -146,11 +146,14 @@ KV_TYPE="${KV_MK_TYPE}" # if we found an output location, use that. otherwise use KERNEL_DIR. - if [ ! -z "${KV_MK_OUTPUT}" ] + if [ -n "${KV_MK_OUTPUT}" ] then KV_OUTPUT="${ROOT}/${KV_MK_OUTPUT}" else - KV_OUTPUT="${KERNEL_DIR}" + if [ -z "${KV_OUTPUT}" ] + then + KV_OUTPUT="${KERNEL_DIR}" + fi fi # KV_OBJ can be used when manually installing kernel modules * end *
I'm a little confused. We are working on migrating away from kmod (its no longer needed, not supported, will be removed, hence this bug), so why are we worrying about it? As for the O= thing, no, I don't think we'll be supporting this (even with kernel-mod) just yet. johnm is planning to rewrite config-kernel, maybe we'll have this kind of functionality then.
Fixed in 6629 and 6111-r3, removing blocks on both.
