* Re: LOCALVERSION_AUTO considered harmful
2010-04-11 22:24 ` Thomas Gleixner
@ 2010-04-12 1:20 ` rdunlap
2010-04-12 2:56 ` rdunlap
2010-04-12 13:14 ` Pavel Machek
2 siblings, 0 replies; 11+ messages in thread
From: rdunlap @ 2010-04-12 1:20 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Pavel Machek, Geert Uytterhoeven, Alexey Dobriyan, kernel list,
Linus Torvalds, Andrew Morton
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 <adobriyan@gmail.com>
>>> 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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: LOCALVERSION_AUTO considered harmful
2010-04-11 22:24 ` Thomas Gleixner
2010-04-12 1:20 ` rdunlap
@ 2010-04-12 2:56 ` rdunlap
2010-04-12 3:49 ` Randy Dunlap
2010-04-12 12:48 ` Theodore Tso
2010-04-12 13:14 ` Pavel Machek
2 siblings, 2 replies; 11+ messages in thread
From: rdunlap @ 2010-04-12 2:56 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Pavel Machek, Geert Uytterhoeven, Alexey Dobriyan, kernel list,
Linus Torvalds, Andrew Morton
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 <adobriyan@gmail.com>
>>> 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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: LOCALVERSION_AUTO considered harmful
2010-04-12 2:56 ` rdunlap
@ 2010-04-12 3:49 ` Randy Dunlap
2010-04-12 12:48 ` Theodore Tso
1 sibling, 0 replies; 11+ messages in thread
From: Randy Dunlap @ 2010-04-12 3:49 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Pavel Machek, Geert Uytterhoeven, Alexey Dobriyan, kernel list,
Linus Torvalds, Andrew Morton
On 04/11/10 19:56, rdunlap@xenotime.net 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 <adobriyan@gmail.com>
>>>> 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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: LOCALVERSION_AUTO considered harmful
2010-04-12 2:56 ` rdunlap
2010-04-12 3:49 ` Randy Dunlap
@ 2010-04-12 12:48 ` Theodore Tso
1 sibling, 0 replies; 11+ messages in thread
From: Theodore Tso @ 2010-04-12 12:48 UTC (permalink / raw)
To: rdunlap
Cc: Thomas Gleixner, Pavel Machek, Geert Uytterhoeven,
Alexey Dobriyan, kernel list, Linus Torvalds, Andrew Morton
On Apr 11, 2010, at 10:56 PM, rdunlap@xenotime.net 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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: LOCALVERSION_AUTO considered harmful
2010-04-11 22:24 ` Thomas Gleixner
2010-04-12 1:20 ` rdunlap
2010-04-12 2:56 ` rdunlap
@ 2010-04-12 13:14 ` Pavel Machek
2010-04-12 17:03 ` Linus Torvalds
2 siblings, 1 reply; 11+ messages in thread
From: Pavel Machek @ 2010-04-12 13:14 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Geert Uytterhoeven, Alexey Dobriyan, kernel list, Linus Torvalds,
Andrew Morton
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: LOCALVERSION_AUTO considered harmful
2010-04-12 13:14 ` Pavel Machek
@ 2010-04-12 17:03 ` Linus Torvalds
0 siblings, 0 replies; 11+ messages in thread
From: Linus Torvalds @ 2010-04-12 17:03 UTC (permalink / raw)
To: Pavel Machek
Cc: Thomas Gleixner, Geert Uytterhoeven, Alexey Dobriyan, kernel list,
Andrew Morton
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
^ permalink raw reply [flat|nested] 11+ messages in thread