On 2015-10-30 15:33, Toke Høiland-Jørgensen wrote:
> Felix Fietkau writes:
>
>>> Would definitely work. The problem is I'm not sure I quite grok the
>>> openwrt build system sufficiently to do this correctly. Guess I need to
>>> get the linker flag into KERNEL_MAKEOPTS?
>> Yes. It's in kernel-def
Felix Fietkau writes:
>> diff --git a/rules.mk b/rules.mk
>> index 819bea5..8e1cfe9 100644
>> --- a/rules.mk
>> +++ b/rules.mk
>> @@ -275,6 +275,7 @@ else
>>endif
>>RSTRIP:= \
> Please try if changing RSTRIP:= to RSTRIP= makes it work.
Yup, it does. Cool, will submit a new patch that als
Felix Fietkau writes:
>> Would definitely work. The problem is I'm not sure I quite grok the
>> openwrt build system sufficiently to do this correctly. Guess I need to
>> get the linker flag into KERNEL_MAKEOPTS?
> Yes. It's in kernel-defaults.mk
Cool, this part works.
>> Can go looking for tha
On 2015-10-30 15:17, Toke Høiland-Jørgensen wrote:
> Felix Fietkau writes:
>
>> How about this: add it per-package, but add it in a way that you can set
>> PKG_BUILD_ID:=$(PKG_SOURCE_VERSION) and this will add the linker command
>> and disable the build-id stripping.
>
> Would definitely work. T
Felix Fietkau writes:
> How about this: add it per-package, but add it in a way that you can set
> PKG_BUILD_ID:=$(PKG_SOURCE_VERSION) and this will add the linker command
> and disable the build-id stripping.
Would definitely work. The problem is I'm not sure I quite grok the
openwrt build syst
On 2015-10-30 15:03, Toke Høiland-Jørgensen wrote:
> Felix Fietkau writes:
>
>> As far as I know, the build-id is build host specific, so I don't think
>> it will really help you with tracking versions of other people's
>> builds.
>
> Yup. But you can pass it explicitly to the linker:
>
> LDFLA
Felix Fietkau writes:
> As far as I know, the build-id is build host specific, so I don't think
> it will really help you with tracking versions of other people's
> builds.
Yup. But you can pass it explicitly to the linker:
LDFLAGS_MODULE=--build-id=0x$(PKG_SOURCE_VERSION)
where PKG_SOURCE_VER
On 2015-10-30 14:37, Toke Høiland-Jørgensen wrote:
> Felix Fietkau writes:
>
>> I'm still not convinced that this is very useful - if you have issues
>> that you sometimes reinstall modules, but don't reload them and have
>> to check the id, why not just fix your workflow instead?
>
> I did scri
Felix Fietkau writes:
> I'm still not convinced that this is very useful - if you have issues
> that you sometimes reinstall modules, but don't reload them and have
> to check the id, why not just fix your workflow instead?
I did script it, but I'm trying to have a way to make this available to
On 2015-10-30 13:54, Toke Høiland-Jørgensen wrote:
> Felix Fietkau writes:
>
>> How is this more useful than simply checking a hash of the kernel
>> module in /lib/modules and comparing that with the corresponding file
>> on the host?
>
> Because the value in /sys/module/ is from the *loaded* mo
Felix Fietkau writes:
> How is this more useful than simply checking a hash of the kernel
> module in /lib/modules and comparing that with the corresponding file
> on the host?
Because the value in /sys/module/ is from the *loaded* module. So it
catches the case where the module file is updated
On 2015-10-30 11:44, Toke Høiland-Jørgensen wrote:
> This change adds support for specifying that a particular kernel module
> wants to keep its build ID debug symbol (.note.gnu.build-id). This
> symbol is exported in sysfs by the kernel (if the kernel is compiled
> with CONFIG_KALLSYMS) and so can
This change adds support for specifying that a particular kernel module
wants to keep its build ID debug symbol (.note.gnu.build-id). This
symbol is exported in sysfs by the kernel (if the kernel is compiled
with CONFIG_KALLSYMS) and so can be used to uniquely identify a version
of a kernel module
13 matches
Mail list logo
