Linus's include file strategy redux
A message that is not in the archive (sent off-list or not yet received): [email protected]
In article <[email protected]> you write:
Quoted 13 lines
In article <[email protected]>,
Quoted 8 lines · LA Walsh
It was at that
point, the externally compiled module "barfed", because like many modules, it expected, like many externally compiled modules, that it could simply access all of it's needed files through/usr/include/linuxwhich it gets by putting/usr/includein it's path. I've seen commercial modules like vmware's kernel modules use a similar system where they expect/usr/include/linuxto contain or point to headers for the currently running kernel.vmware asks you nicely
Quoted 7 lines
where are the running kernels include files [
/usr/src/linux/include" >And then compiles the modules with -I/path/to/include/files
In fact, the 2.2.18 kernel already puts a 'build' symlink in
/lib/modules/uname -rthat points to the kernel source, which should be sufficient to solve this problem.. almost.
Don't get me started on that... The link points back to where the code was when it was built, not where it is installed. This makes a difference if you're building RPMs... in which case the link points back to (for example) /usr/src/sgi/BUILD/linux-<version> and not /usr/src/linux-<version>/.
And, top it all... once the build is completed the BUILD directory is deleted.
Good Idea, but poorly thought out.
Quoted 4 lines
I think
/lib/modules/uname -r/ should contain a script that reproduces the CFLAGS used to compile the kernel. That way, you not only get the correct -I/path/to/kernel/include but the other compile-time flags (like -m486 etc) as well.
Anything that uses uname to work out what kernel is running doesn't work if you're in a chrooted environment. Symlinks work better for this...if all fails you can manage them manually during the build...
[ changeling 2.2.15-#5 ] uname -r
2.2.15-3SGI_39
[ changeling 2.2.15-#5 ] echo $ROOT
/work/root
[ changeling 2.2.15-#5 ] sudo chroot $ROOT
[ changeling 2.2.15-#5 ] uname -r
2.2.15-3SGI_39
[ changeling 2.2.15-#5 ] rpm -qa | grep kernel
kernel-headers-2.2.16-3
kernel-2.2.16-3
Trust me, $ROOT does not include 2.2.15....
Quoted 1 line
Mike.
richard.
-----------------------------------------------------------------------
Richard Offer Widget FAQ --> http://reality.sgi.com/widgetFAQ/
{X,Motif,Trust} on {Irix,Linux} __________________________________________http://reality.sgi.com/offer/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
What about 'kernel package'? was: Re: Linus's include file strategy redux
Quoted 28 lines · richard offer
In article <[email protected]> you write:
Quoted 13 lines
In article <[email protected]>,
Quoted 8 lines · LA Walsh
It was at that
point, the externally compiled module "barfed", because like many modules, it expected, like many externally compiled modules, that it could simply access all of it's needed files through/usr/include/linuxwhich it gets by putting/usr/includein it's path. I've seen commercial modules like vmware's kernel modules use a similar system where they expect/usr/include/linuxto contain or point to headers for the currently running kernel.vmware asks you nicely
Quoted 7 lines
where are the running kernels include files [
/usr/src/linux/include" >And then compiles the modules with -I/path/to/include/files
In fact, the 2.2.18 kernel already puts a 'build' symlink in
/lib/modules/uname -rthat points to the kernel source, which should be sufficient to solve this problem.. almost.Don't get me started on that... The link points back to where the code was when it was built, not where it is installed. This makes a difference if you're building RPMs... in which case the link points back to (for example) /usr/src/sgi/BUILD/linux-<version> and not /usr/src/linux-<version>/.
Quoted 5 lines
And, top it all... once the build is completed the BUILD directory is deleted.
Good Idea, but poorly thought out.
[snip]
Once again, I'd like to suggest Debian's kernel package system as a good working example of this sort of administrative-level kernel management. I brought this up on the list once before, maybe eight months ago, but I recall not even one reply worth of discussion about it. I have a fairly basic idea of what could be done to merge part of 'make-kpkg' into the kernel-side management, but I'd like to see some other trained eyeballs taking a look.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/