LOCALVERSION_AUTO has nasty interaction with modules, warn about it.
Signed-off-by: Pavel Machek <[email protected]>
diff --git a/init/Kconfig b/init/Kconfig
index eb77e8c..5d33072 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -88,7 +88,6 @@ config LOCALVERSION
config LOCALVERSION_AUTO
bool "Automatically append version information to the version string"
- default y
help
This will try to automatically determine if the current tree is a
release tree by looking for git tags that belong to the current
@@ -99,6 +98,11 @@ config LOCALVERSION_AUTO
appended after any matching localversion* files, and after the value
set in CONFIG_LOCALVERSION.
+ Unfortunately, such finegrained versioning will mean that you will
+ not be able to use modules for development; even "make modules"
+ will change module versions, making recompiled modules impossible
+ to insert into old kernel.
+
(The actual string used here is the first eight characters produced
by running the command:
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Sun, Apr 11, 2010 at 06:47:01PM +0200, Pavel Machek wrote:
> @@ -99,6 +98,11 @@ config LOCALVERSION_AUTO
> appended after any matching localversion* files, and after the value
> set in CONFIG_LOCALVERSION.
>
> + Unfortunately, such finegrained versioning will mean that you will
> + not be able to use modules for development; even "make modules"
> + will change module versions, making recompiled modules impossible
> + to insert into old kernel.
That's conditional BS.
Turn off CONFIG_MODVERSIONS already.
On Mon, Apr 12, 2010 at 20:51, Alexey Dobriyan <[email protected]> wrote:
> On Sun, Apr 11, 2010 at 06:47:01PM +0200, Pavel Machek wrote:
>> @@ -99,6 +98,11 @@ config LOCALVERSION_AUTO
>> appended after any matching localversion* files, and after the value
>> set in CONFIG_LOCALVERSION.
>>
>> + Unfortunately, such finegrained versioning will mean that you will
>> + not be able to use modules for development; even "make modules"
>> + will change module versions, making recompiled modules impossible
>> + to insert into old kernel.
>
> That's conditional BS.
> Turn off CONFIG_MODVERSIONS already.
Yeah, I disabled it ages ago. Even then (before git, probably even
before bitkeeper)
I had hard times inserting modules...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Sun 2010-04-11 20:58:58, Geert Uytterhoeven wrote:
> On Mon, Apr 12, 2010 at 20:51, Alexey Dobriyan <[email protected]> wrote:
> > On Sun, Apr 11, 2010 at 06:47:01PM +0200, Pavel Machek wrote:
> >> @@ -99,6 +98,11 @@ config LOCALVERSION_AUTO
> >> ? ? ? ? appended after any matching localversion* files, and after the value
> >> ? ? ? ? set in CONFIG_LOCALVERSION.
> >>
> >> + ? ? ? Unfortunately, such finegrained versioning will mean that you will
> >> + ? ? ? not be able to use modules for development; even "make modules"
> >> + ? ? ? will change module versions, making recompiled modules impossible
> >> + ? ? ? to insert into old kernel.
> >
> > That's conditional BS.
> > Turn off CONFIG_MODVERSIONS already.
>
> Yeah, I disabled it ages ago. Even then (before git, probably even
> before bitkeeper)
> I had hard times inserting modules...
I _had_ it off
# CONFIG_MODVERSIONS is not set
It seems some checking survives CONFIG_MODVERSIONS unset and that
checking is strict enough to refuse module load after one "make
modules" with LOCALVERSION_AUTO on...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Sun, 11 Apr 2010, Pavel Machek wrote:
> On Sun 2010-04-11 20:58:58, Geert Uytterhoeven wrote:
> > On Mon, Apr 12, 2010 at 20:51, Alexey Dobriyan <[email protected]> wrote:
> > > On Sun, Apr 11, 2010 at 06:47:01PM +0200, Pavel Machek wrote:
> > >> @@ -99,6 +98,11 @@ config LOCALVERSION_AUTO
> > >> ? ? ? ? appended after any matching localversion* files, and after the value
> > >> ? ? ? ? set in CONFIG_LOCALVERSION.
> > >>
> > >> + ? ? ? Unfortunately, such finegrained versioning will mean that you will
> > >> + ? ? ? not be able to use modules for development; even "make modules"
> > >> + ? ? ? will change module versions, making recompiled modules impossible
> > >> + ? ? ? to insert into old kernel.
> > >
> > > That's conditional BS.
> > > Turn off CONFIG_MODVERSIONS already.
> >
> > Yeah, I disabled it ages ago. Even then (before git, probably even
> > before bitkeeper)
> > I had hard times inserting modules...
>
> I _had_ it off
>
> # CONFIG_MODVERSIONS is not set
>
> It seems some checking survives CONFIG_MODVERSIONS unset and that
> checking is strict enough to refuse module load after one "make
> modules" with LOCALVERSION_AUTO on...
So instead of fixing the CONFIG_MODVERSIONS=n case you go the easy way
of killing LOCALVERSION_AUTO ? Brilliant.
Thanks,
tglx
On Sun, April 11, 2010 3:24 pm, Thomas Gleixner wrote:
> On Sun, 11 Apr 2010, Pavel Machek wrote:
>
>
>> On Sun 2010-04-11 20:58:58, Geert Uytterhoeven wrote:
>>
>>> On Mon, Apr 12, 2010 at 20:51, Alexey Dobriyan <[email protected]>
>>> wrote:
>>>
>>>> On Sun, Apr 11, 2010 at 06:47:01PM +0200, Pavel Machek wrote:
>>>>
>>>>> @@ -99,6 +98,11 @@ config LOCALVERSION_AUTO
>>>>> ? ? ? ? appended after any matching localversion* files, and after
>>>>> the value ? ? ? ? set in CONFIG_LOCALVERSION.
>>>>>
>>>>>
>>>>> + ? ? ? Unfortunately, such finegrained versioning will mean that
>>>>> you will + ? ? ? not be able to use modules for development; even
>>>>> "make modules"
>>>>> + ? ? ? will change module versions, making recompiled modules
>>>>> impossible + ? ? ? to insert into old kernel.
>>>>>
>>>>
>>>> That's conditional BS.
>>>> Turn off CONFIG_MODVERSIONS already.
>>>>
>>>
>>> Yeah, I disabled it ages ago. Even then (before git, probably even
>>> before bitkeeper) I had hard times inserting modules...
>>>
>>
>> I _had_ it off
>>
>>
>> # CONFIG_MODVERSIONS is not set
>>
>>
>> It seems some checking survives CONFIG_MODVERSIONS unset and that
>> checking is strict enough to refuse module load after one "make modules"
>> with LOCALVERSION_AUTO on...
>
> So instead of fixing the CONFIG_MODVERSIONS=n case you go the easy way
> of killing LOCALVERSION_AUTO ? Brilliant.
so it works for you? how so, please?
> Thanks,
(saving bits)
~Randy
On Sun, April 11, 2010 3:24 pm, Thomas Gleixner wrote:
> On Sun, 11 Apr 2010, Pavel Machek wrote:
>
>
>> On Sun 2010-04-11 20:58:58, Geert Uytterhoeven wrote:
>>
>>> On Mon, Apr 12, 2010 at 20:51, Alexey Dobriyan <[email protected]>
>>> wrote:
>>>
>>>> On Sun, Apr 11, 2010 at 06:47:01PM +0200, Pavel Machek wrote:
>>>>
>>>>> @@ -99,6 +98,11 @@ config LOCALVERSION_AUTO
>>>>> ? ? ? ? appended after any matching localversion* files, and after
>>>>> the value ? ? ? ? set in CONFIG_LOCALVERSION.
>>>>>
>>>>>
>>>>> + ? ? ? Unfortunately, such finegrained versioning will mean that
>>>>> you will + ? ? ? not be able to use modules for development; even
>>>>> "make modules"
>>>>> + ? ? ? will change module versions, making recompiled modules
>>>>> impossible + ? ? ? to insert into old kernel.
>>>>>
>>>>
>>>> That's conditional BS.
>>>> Turn off CONFIG_MODVERSIONS already.
>>>>
>>>
>>> Yeah, I disabled it ages ago. Even then (before git, probably even
>>> before bitkeeper) I had hard times inserting modules...
>>>
>>
>> I _had_ it off
>>
>>
>> # CONFIG_MODVERSIONS is not set
>>
>>
>> It seems some checking survives CONFIG_MODVERSIONS unset and that
>> checking is strict enough to refuse module load after one "make modules"
>> with LOCALVERSION_AUTO on...
>
> So instead of fixing the CONFIG_MODVERSIONS=n case you go the easy way
> of killing LOCALVERSION_AUTO ? Brilliant.
Pavel's original example (afaik) was on April 5:
Subject: 2.6.34-rc3: Can't insmod after make, because versions now differ?!
Apr 5 07:33:16 amd kernel: udlfb: version magic
'2.6.34-rc3-00345-ge8240f9-dirty SMP mod_unload CORE2 ' should be
'2.6.34-rc3-00344-g548fc0a-dirty SMP mod_unload CORE2 '
So what do you suggest? If the "magic" strings contain "-dirty ",
then ignore that and the 2 preceding hyphen-separated fields?
That could be dangerous if some kernel internal structures have changed.
I.e., user/developer beware.
Maybe ignore those strings iff some override has been set somewhere?
---
~Randy
On 04/11/10 19:56, [email protected] wrote:
> On Sun, April 11, 2010 3:24 pm, Thomas Gleixner wrote:
>> On Sun, 11 Apr 2010, Pavel Machek wrote:
>>
>>
>>> On Sun 2010-04-11 20:58:58, Geert Uytterhoeven wrote:
>>>
>>>> On Mon, Apr 12, 2010 at 20:51, Alexey Dobriyan <[email protected]>
>>>> wrote:
>>>>
>>>>> On Sun, Apr 11, 2010 at 06:47:01PM +0200, Pavel Machek wrote:
>>>>>
>>>>>> @@ -99,6 +98,11 @@ config LOCALVERSION_AUTO
>>>>>> appended after any matching localversion* files, and after
>>>>>> the value set in CONFIG_LOCALVERSION.
>>>>>>
>>>>>>
>>>>>> + Unfortunately, such finegrained versioning will mean that
>>>>>> you will + not be able to use modules for development; even
>>>>>> "make modules"
>>>>>> + will change module versions, making recompiled modules
>>>>>> impossible + to insert into old kernel.
>>>>>>
>>>>>
>>>>> That's conditional BS.
>>>>> Turn off CONFIG_MODVERSIONS already.
>>>>>
>>>>
>>>> Yeah, I disabled it ages ago. Even then (before git, probably even
>>>> before bitkeeper) I had hard times inserting modules...
>>>>
>>>
>>> I _had_ it off
>>>
>>>
>>> # CONFIG_MODVERSIONS is not set
>>>
>>>
>>> It seems some checking survives CONFIG_MODVERSIONS unset and that
>>> checking is strict enough to refuse module load after one "make modules"
>>> with LOCALVERSION_AUTO on...
>>
>> So instead of fixing the CONFIG_MODVERSIONS=n case you go the easy way
>> of killing LOCALVERSION_AUTO ? Brilliant.
>
> Pavel's original example (afaik) was on April 5:
> Subject: 2.6.34-rc3: Can't insmod after make, because versions now differ?!
>
> Apr 5 07:33:16 amd kernel: udlfb: version magic
> '2.6.34-rc3-00345-ge8240f9-dirty SMP mod_unload CORE2 ' should be
> '2.6.34-rc3-00344-g548fc0a-dirty SMP mod_unload CORE2 '
>
>
> So what do you suggest? If the "magic" strings contain "-dirty ",
> then ignore that and the 2 preceding hyphen-separated fields?
>
> That could be dangerous if some kernel internal structures have changed.
> I.e., user/developer beware.
>
> Maybe ignore those strings iff some override has been set somewhere?
Pavel, does "modprobe --force" work?
--
~Randy
On Apr 11, 2010, at 10:56 PM, [email protected] wrote:
>
> So what do you suggest? If the "magic" strings contain "-dirty ",
> then ignore that and the 2 preceding hyphen-separated fields?
I have a standard local patch that I've been carrying for I-don't-know-how-long which just nukes the "-dirty" suffix, which I needed because make-kpkg modifies some kernel build files, so the version string would always have
-dirty.
It's not hard to fix...
-- Ted
Hi!
> > > > That's conditional BS.
> > > > Turn off CONFIG_MODVERSIONS already.
> > >
> > > Yeah, I disabled it ages ago. Even then (before git, probably even
> > > before bitkeeper)
> > > I had hard times inserting modules...
> >
> > I _had_ it off
> >
> > # CONFIG_MODVERSIONS is not set
> >
> > It seems some checking survives CONFIG_MODVERSIONS unset and that
> > checking is strict enough to refuse module load after one "make
> > modules" with LOCALVERSION_AUTO on...
>
> So instead of fixing the CONFIG_MODVERSIONS=n case you go the easy way
> of killing LOCALVERSION_AUTO ? Brilliant.
In previous discussion, I was told that there's no bug to fix, that
everything works as intended.
I believe current behaiour is stupid, and I'd prefer *some* fix.
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Mon, 12 Apr 2010, Pavel Machek wrote:
> Hi!
>
> > > > > That's conditional BS.
> > > > > Turn off CONFIG_MODVERSIONS already.
> > > >
> > > > Yeah, I disabled it ages ago. Even then (before git, probably even
> > > > before bitkeeper)
> > > > I had hard times inserting modules...
> > >
> > > I _had_ it off
> > >
> > > # CONFIG_MODVERSIONS is not set
> > >
> > > It seems some checking survives CONFIG_MODVERSIONS unset and that
> > > checking is strict enough to refuse module load after one "make
> > > modules" with LOCALVERSION_AUTO on...
> >
> > So instead of fixing the CONFIG_MODVERSIONS=n case you go the easy way
> > of killing LOCALVERSION_AUTO ? Brilliant.
>
> In previous discussion, I was told that there's no bug to fix, that
> everything works as intended.
The problem is that you guys are looking at CONFIG_MODVERSIONS the wrong
way around.
It's the _off_ case that is broken. Always was, always will be.
If CONFIG_MODVERSIONS is off, we remove the symbol versioning, and replace
it with the _insane_ kernel version check. That is never valid. The fact
that the kernel version is the same doesn't mean that the module will
work, since we often do lots of changes within the same version.
So the solution is to say CONFIG_MODVERSIONS=y, and everybody is happy.
Your modules will actually test things that _matter_, and will stop
loading if the data types or function prototypes have changed.
Linus