Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 46592 - nvidia-kernel changes for new koutput feature
Summary: nvidia-kernel changes for new koutput feature
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All All
: High enhancement (vote)
Assignee: Gentoo X packagers
Depends on:
Reported: 2004-04-02 06:14 UTC by Peter Johanson (RETIRED)
Modified: 2004-06-16 06:35 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---

Ebuild enhanced with koutput compatibility (nvidia-kernel-1.0.5336-r2.ebuild,4.08 KB, text/plain)
2004-04-02 06:16 UTC, Peter Johanson (RETIRED)
nvidia-kernel-1.0.5336-r2.ebuild (nvidia-kernel-1.0.5336-r2.ebuild,4.15 KB, text/plain)
2004-04-13 07:58 UTC, Donnie Berkholz (RETIRED)

Note You need to log in before you can comment on or make changes to this bug.
Description Peter Johanson (RETIRED) gentoo-dev 2004-04-02 06:14:48 UTC
Johnm and I are hoping to get the koutput features merged this saturday (april 3rd) and we would *really* like to have nvidia-kernel working with this feature the moment we add support for it. But as it's a pretty key ebuild, we wanted to get sign-off on it before mucking with things. (:

I will attach the ebuild for your inspection, here's a summary of what is changed from the latest ebuild in portage:

1) Don't check /proc/mtrr as it's policy to check the kernel config, and not what's found on the "live system" when checking for various kernel support items.

2) kmod_src_unpack handles calling check_KV, etc to make sure we have a sane environment.

3) the new kmod.eclass provides an "is kernel MAJOR MINOR" function, so a function for that in the ebuild is not required.

4) Besides the above changes, the only difference is the way the module gets built if is_koutput returns true. This will only happen when that feature is enabled, so other users should notice no change what-so-ever.

If you'd like to test this, i have an overlay tarball with all of the eclasses/ebuilds and a README with instructions available at
Bug #32737 has all the gory details, and you can read the new user and develop docs on this at:

Thanks, attachment to follow.
Comment 1 Peter Johanson (RETIRED) gentoo-dev 2004-04-02 06:16:14 UTC
Created attachment 28570 [details]
Ebuild enhanced with koutput compatibility

Here's the changed ebuild.
Comment 2 Donnie Berkholz (RETIRED) gentoo-dev 2004-04-02 14:07:43 UTC
I'll revision bump with these changes if they look good -- haven't had a chance to check yet.
Comment 3 John Mylchreest (RETIRED) gentoo-dev 2004-04-02 14:17:12 UTC
would you please be able to bump and hard mask it.
it would then allow us to unmask it when were ready to commit the rest of the solution :)
Comment 4 Donnie Berkholz (RETIRED) gentoo-dev 2004-04-13 07:58:52 UTC
Created attachment 29202 [details]

I couldn't get this to work locally, it has a few modifications from yours.
Comment 5 Andrew Bevitt 2004-04-16 02:18:35 UTC
I could get kernels to compile into the external directory.

But I could not get nvidia-kernel to build using this style of kernel... effectivly I put this down to include problems, as 
linux/version.h : is under /var/tmp/...
but is included from /usr/src/linux/include/linux/config.h, which unforunately does not work with the current Makefile setup. Futher more include/asm/* is actually stored at SYSSRC_OUTPUT/include2/asm which futher breaks build processes.

I feel that the actual KERNEL should be built inside /usr/src/linux, as kernel compilation is done outside of portage, hence should NOT have the same restrictions on it as portage does. However nvidia-kernel and other such modules should be built outside of the source repository, which I think is what nvidia was trying to have done with their vanilla Makefile.kbuild...

In futherance it is important we get this working because non-kbuilded nvidia modules will not load into the 2.6.6_rc1 kernel :( (no module found in object).

There are few changes (udev support primarily) in the current 5336-r2 ebuild btw latexer
Comment 6 Andrew Bevitt 2004-04-16 03:29:08 UTC
Futhermore (from 2.6.6_rc1 Changelog probably useful in this)

	[PATCH] kbuild: external module support
	From: Sam Ravnborg <>
	Based on initial patch from Andreas Gruenbacher there is now better support	for building external modules with kbuild.
	The preferred syntax is now:
	but the old syntax:
	make -C $KERNELSRC SUBDIRS=$PWD modules
	will remain supported.
	The major differences compared to before are that:
	1) No attempt is made to neither check nor update any files in $KERNELSRC
	2) Module versions are now supported
	During stage 2 of kernel compilation where the modules are built, a new file
	Module.symvers is created.  This file contains the version for all symbols exported by the kernel and any module compiled within the kernel tree.
	When the external module is build the Module.symvers file is being read and symbol versions are used from that file.
	The purpose of avoiding any updates in the kernel src is that usually in a distribution the kernel src will be read-only, and there is no need to try to update it.  And when building an external module the focus is on the module, not the kernel.
	I expect the distributions will start using something like this:
	kernel src - with no generated files. Not even .config:
	Output from build:
	where build is a real directory with relevant output files and the
	appropriate .config.
	I have some Documentation in the pipe-line, but wants to see how this
	approach is received before completing it.
	This patch is made on top of the previously posted patch to divide
	make clean in three steps.
	And you may need to edit the following line in the patch to make it apply:
	 %docs: scripts_basic FORCE
	 %docs: scripts FORCE
Comment 7 Peter Johanson (RETIRED) gentoo-dev 2004-04-16 09:08:15 UTC

See bug #32737 for the details of why we need to build the kernel stuff to elsewhere. If we don't any attempts to use O= magic fail, because the tree is dirty and it has no idea what files to create where (annoying, yes). If we want to use O= in any module ebuilds, we need a clean kernel tree (ergo the config-kernel stuff and setting KBUILD_OUTPUT in the makefile.

As for the nvidia-kernel stuff, both johnm and i have tested it with no problems, so i'm not sure where your include issues are arising from. Lets meet on IRC where we can more easily debug/see what you have going.

As for the delays, I've had major issues with my Optimum Online cable at my apartment the past few weeks, with it going down both saturdays i had free to start merging some of this support. grr.
Comment 8 Andrew Bevitt 2004-06-12 00:24:04 UTC
This seems to be working nicely in 5336-r3 atm...
Comment 9 Martin Schlemmer (RETIRED) gentoo-dev 2004-06-15 14:30:45 UTC
Can we close this?
Comment 10 Donnie Berkholz (RETIRED) gentoo-dev 2004-06-15 15:21:39 UTC
Are the M= changes in yet?
Comment 11 Martin Schlemmer (RETIRED) gentoo-dev 2004-06-15 17:20:05 UTC
Yeah, check -r3 and -r4 ...
Comment 12 Martin Schlemmer (RETIRED) gentoo-dev 2004-06-15 17:21:39 UTC
Note that -r4 will not be easy to spot - you will have to check the
files/1.0.5336/NVIDIA_kernel-1.0-5336-fix-makefile-for-2.6.patch patch ...
Comment 13 Donnie Berkholz (RETIRED) gentoo-dev 2004-06-15 17:25:46 UTC
No access to Gentoo at the moment -- I'm at work. Thanks for confirming.
Comment 14 Andrew Bevitt 2004-06-15 17:28:49 UTC
Yeah we can close this... 

Kernel support for koutput isnt total across the kernels but the ebuild worries about that so im happy :)
Comment 15 Martin Schlemmer (RETIRED) gentoo-dev 2004-06-16 06:35:42 UTC