Upgrade to post uapi kernel (3.7+)

[justincormack]

Given that some work was done on the headers with the uapi project, it would be good to upgrade to this before doing loads of patching as there are a lot of changes so patches are likely not to apply well. This was in 3.7.

[rofl0r]

i think we should upgrade soon to 3.12.6, this is what debian uses currently for all archs so the headers should be quite stable. musl-cross also switched to them a few days ago. if we get it right musl-cross might just include our headers instead of downloading the entire kernel tarball, extracting it and building the headers, which takes far too long for my taste. (it's also planned to ship musl-cross with sabotage soon, so one can for example butch install musl-cross-mips)

[justincormack]

That sounds good.

I think it might be best to move the current version to a branch, then import an clean set, then look at cherry picking changes if applicable - there are going to be a lot of changes with uapi.

[justincormack]

Also I think I will try upstreaming fixes to glibc, as they seem to be interested in header fixes now.

[justincormack]

Ok I have done an update to clean 3.12.6, will do some tests and make sure its all looking ok...

[justincormack]

Ugh there are some issues, need to sort out uapi...

[justincormack]

SIgh, I thought this might be relatively straightforward. Need to do some more experimentation...

[justincormack]

OK, its in a better state now.

[rofl0r]

in case you want to create the headers for all supported archs, the quickest way to do so is by using musl cross, and modifying the part that installs the kernel headers to install it as well into a different location provided by you. the current musl-cross supports something like ARCH=arm ./build.sh so it's pretty easy to automate.

[rofl0r]

btw, musl-cross now supports microblaze as well...

[rofl0r]

it seems you imported some superfluous files as well : ".install" "..install.cmd" (i guess those are created due to some bug in the kernel header generation)

may i ask how you built the headers that you committed just now ?

[justincormack]

those are from make_headers_install_all on the kernel tree. Can clean up the extra files, just trying to see if they look sane... (apologies for making such a mess of this).

[rofl0r]

did you do so with an appropriate crosscompiler ?

[rofl0r]

it seems the way you create the headers is correct, i just made a manual arm headers_install with the crosscompiler and the result is identical.

[justincormack]

It seemed ok, it complained about missing compilers on some other archs, arc-linux-uclibc-gcc etc but none that are using.

[rofl0r]

so it looks as if with the uapi change the headers are the same for all archs, except of one arch specific dir, right ? if so, we could create a directory generic/, and symlink each archs subfolders there to save from duplicates.

[justincormack]

Yes, that would be nicer, will do.

Have documented the process here https://github.com/sabotage-linux/kernel-headers/blob/master/UPDATE.sh

[rofl0r]

cool thanks. yes, me reading that file is what lead to above question ;)

[rofl0r]

hmm there's some difference for mips:

Only in /tmp/linux-3.12.6/dest/include/: linux/kvm.h Only in /tmp/linux-3.12.6/dest/include/: linux/kvm_para.h

[justincormack]

Yes I saw some issues about linux/kvm.h only being available for archs that support kvm, might need to tweak those (which way round is that?)

[rofl0r]

what i did was: extract kernel, cd there and

make v=1 CC=~/musl-cross-4.8.2/mips-linux-musl/bin/mips-linux-musl-gcc HOSTCC=gcc ARCH=mips HOSTCFLAGS=-D_GNU_SOURCE INSTALL_HDR_PATH=dest headers_install

i'm unsure what you mean with "which way round" ?

[justincormack]

Yes, there seems to be a known issue that make_headers_install_all ends up deleting linux/kvm.h and linux/a.out.h as they are not present in some architectures.

[rofl0r]

if they are the same for all archs, i think we can just ship them unconditionally (i.e. just symlink arch/include/linux to arch/generic/linux without further ado)

[rofl0r]

alternatively we may add a tiny makefile that just provides make install and deletes those headers if the target arch does not support them (if their mere existance could cause build errors)

[justincormack]

It seems that kvm supports mips and ppc which came as a surprise, as well as arm, x86.

[rofl0r]

cool, in that case we can just use them everywhere (even on microblaze)

[justincormack]

ok, its symlinked and has the missing headers now....

[justincormack]

and microblaze.

[rofl0r]

good work, thanks! do you think the headers are now in a shape to make a release ? or did you intend to do some tests first with your luasyscall framework ?

[justincormack]

Yes its good to go, I just reverted the only fix I am unsure about as it is inconsistent with standard header sets, will think about this one some more first. Otherwise seems good.

[rofl0r]

hmm the uapi symlinks are dead links, i.e. generic/include/uapi is missing

[justincormack]

ok, this is a bit odd. Basically the uapi directory is created by the build but is empty. On my Ubuntu system /usr/include/uapi exists and is empty. git ignores empty dirs. I guess the options are to create it empty on install or just delete them all...

[rofl0r]

ok, i deleted them. i guess we'll see some day what it's purpose is...