[PATCH] Use the pcf50633 APM emulation code (applies to -andy branch)

Mike (mwester) mwester at dls.net
Sun Jul 27 15:18:01 CEST 2008


Michael 'Mickey' Lauer wrote:

> -# CONFIG_IKCONFIG is not set
> +CONFIG_IKCONFIG=y
> +CONFIG_IKCONFIG_PROC=y


:)  We really need that in *all* the defconfigs, it would ensure that
when in doubt each user could provide the defconfig for their running
kernel.


----

Another thing that should be given some thought is to encode additional
information when the kernel is built. Consider:

Linux version 2.6.24 (mwester at blocks) (gcc version 4.1.2) #76 PREEMPT
Sat Jul 26 08:55:13 CDT 2008

Lots of useful information, and "mwester at blocks" is rather significant
in that it would tell someone reviewing a dmesg output log that this is
a custom kernel.  So that's good.

But we can do better.  Consider that the standard kernels are all built
on specific build servers, and that we really don't care about the
username that built the kernel.  I'd much rather know what specific
version of the source code was used, particularly when I'm looking at a
bug report.


If the bitbake recipe for the kernel build were to replace just the
username with the version information for that particular kernel build,
then the "user at machine" could be potentially significant in bug
reporting. The machine name portion would differentiate kernels built on
the official OM buildhost from those built using OM or OE by the
community, and strings that have the default format would indicate
kernels built from the git repo without OM or OE.

Example:

"(git0+66a83c97c4545ce4f07e0d90998f906fae49caf2-r0 at buildhost)" might be
the OM official build.  I rather suspect the username will be too long;
it would be reasonable to trim it in the normal fashion, similar to
shortening git identifiers.


The down-side is that it's another patch that would be specific to
OE/OM, although it would be a build-time sort of patch, and would be
simple to review to assure skeptics that it won't affect other run-time
behavior.


Mike (mwester)




More information about the openmoko-kernel mailing list