Problem building a module for x86-generic using sys-kernel/chromeos-kernel-next

[GH]

I just went through the entire process (setup and build) to create a
new usb image for x86-generic using kernel-next. After building the
usb image, I wanted to build a module so I built the kernel using the
command ./bin/cros_workon_make sys-kernel/chromeos-kernel-next. Then,
I was able to successfully build my module, but the magic version
number the kernel has does not match what my module has. The kernel
wants it to be '2.6.37 SMP mod_unload 686' but the module has
'2.6.37-23101.gc987f16 SMP mod_unload 686'. Can anyone tell me how to
resolve this problem?

[GH]

It seems like either my process for getting the kernel headers is
incorrect, or this is a bug because previously I went through the same
process using chromeos-kernel and the magic version string matched.

[GH]

To work around this issue where cros_workon_make ends up with a
different magic version number compared to when build_packages builds
kernel-next, I built kernel-next using emerge with the noclean option.
FEATURES=noclean emerge-x86-generic sys-kernel/chromeos-kernel-next

Then I built my kernel modules using the following for the kernel
headers:
/build/x86-generic/tmp/portage/sys-kernel/chromeos-kernel-next-9999/
work/chromeos-kernel-next-9999/

Now my kernel and module use the magic version number '2.6.37 SMP
mod_unload 686'. It seems like a bug that build_packages and emerge
have simply 2.6.37 for the kernel version. I don't know a lot about
emerge, so I wasn't able to figure out how to change things so the
version number would be (what I think is correct)
'2.6.37-23101.gc987f16 SMP mod_unload 686', which is what
cros_workon_make generates while building sys-kernel/chromeos-kernel-
next.

[Simon Glass]

Hi,

I think you have answered your own questions, and I am not sure which way you want it, but I think this is just the kernel Makefile appending the git commit hash to the version. You can probably change the top level Makefile to stop it doing that if you like. See the comment 'Store (new) KERNELRELASE string...'

Also see the kernel's LOCALVERSION_AUTO option.

Regards,

Simon

--
Chromium OS Developers mailing list: chromiu...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-os-dev?hl=en

[GH]

Hi,

Thanks for the info, I had ran a search for kernel.release in the
source and found that Makefile reference you mentioned. What I wasn't
able to figure out is why build_packages and cros_workon_make result
in a different kernel.release files being generated.

Do you think this is a bug and I should report it?

> > Chromium OS Developers mailing list: chromium-os-...@chromium.org

[Jonathan Kliegman]

There was a recent CL that changed this behavior that set the flag mentioned above.

When the kernel builds now it attaches the git commit ID as part of the version string.  If the repo is dirty (uncommitted files) it appends -dirty to the version line.

If you are doing custom builds of the kernel its probably worth it to always do a fresh build of the kernel and install that to the board and then start building changed modules. 

The case where this is most likely to cause trouble is:
Make changes

Commit

Build kernel & deploy

Make some changes

Copy new module directly to device

As the changes you make will cause the tree to either be dirty or have a new commit ID.  

I'm still trying to figure out the best workflow for myself on this as its easier to ship a new module to the board than a new kernel for testing.  Although there are some scripts designed for shipping a kernel to a running board (update_kernel).  

-Jon

Chromium OS Developers mailing list: chromiu...@chromium.org