3:43 p.m.
I sent this message to fedora-list(a)redhat.com but i had no reaction so i
try also the devel one because i find this is problem we have to solve
for the core and extras merge, no ?
I'm tired to have problems with rt2500 driver at each new fedora kernel
release because the versionning seems to not follow standards :
http://rt2x00.serialmonkey.com/phpBB2/viewtopic.php?t=2965
What do you think about this ?
Someone have similar problems with other modules ?
Eric
3:43 p.m.
Tanguy Eric wrote:
I sent this message to fedora-list(a)redhat.com but i had no reaction
so i
try also the devel one because i find this is problem we have to solve
for the core and extras merge, no ?
I'm tired to have problems with rt2500 driver at each new fedora kernel
release because the versionning seems to not follow standards :
http://rt2x00.serialmonkey.com/phpBB2/viewtopic.php?t=2965
What do you think about this ?
Someone have similar problems with other modules ?
This one is going all the way up to Linus since apparently he prefers
the current naming. See
http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20070111
for the glorious details.
Rahul
3:49 p.m.
On Mon, 2007-01-22 at 22:43 +0100, Tanguy Eric wrote:
I sent this message to fedora-list(a)redhat.com but i had no reaction
so i
try also the devel one because i find this is problem we have to solve
for the core and extras merge, no ?
No.
I'm tired to have problems with rt2500 driver at each new fedora
kernel
release because the versionning seems to not follow standards :
http://rt2x00.serialmonkey.com/phpBB2/viewtopic.php?t=2965
What do you think about this ?
The solution is to get the drivers into the upstream kernel. Period.
josh
3:55 p.m.
Le lundi 22 janvier 2007 à 15:49 -0600, Josh Boyer a écrit :
On Mon, 2007-01-22 at 22:43 +0100, Tanguy Eric wrote:
> I sent this message to fedora-list(a)redhat.com but i had no reaction so i
> try also the devel one because i find this is problem we have to solve
> for the core and extras merge, no ?
No.
> I'm tired to have problems with rt2500 driver at each new fedora kernel
> release because the versionning seems to not follow standards :
> http://rt2x00.serialmonkey.com/phpBB2/viewtopic.php?t=2965
>
> What do you think about this ?
The solution is to get the drivers into the upstream kernel. Period.
josh
Ok but this driver will be into upstream kernel but not before 2.6.21 at
least AFAIK so what can i do before this time ?
Eric
4:04 p.m.
Le mardi 23 janvier 2007 à 03:13 +0530, Rahul Sundaram a écrit :
Tanguy Eric wrote:
> I sent this message to fedora-list(a)redhat.com but i had no reaction so i
> try also the devel one because i find this is problem we have to solve
> for the core and extras merge, no ?
>
> I'm tired to have problems with rt2500 driver at each new fedora kernel
> release because the versionning seems to not follow standards :
> http://rt2x00.serialmonkey.com/phpBB2/viewtopic.php?t=2965
>
> What do you think about this ?
>
> Someone have similar problems with other modules ?
This one is going all the way up to Linus since apparently he prefers
the current naming. See
http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20070111
for the glorious details.
Rahul
Ok but my problem is not really the kernel name but how a driver can
detect correctly the kernel version and eventually the backported patch
to compile fine ...
Eric
4:13 p.m.
Tanguy Eric wrote:
Le mardi 23 janvier 2007 à 03:13 +0530, Rahul Sundaram a écrit :
> Tanguy Eric wrote:
>> I sent this message to fedora-list(a)redhat.com but i had no reaction so i
>> try also the devel one because i find this is problem we have to solve
>> for the core and extras merge, no ?
>>
>> I'm tired to have problems with rt2500 driver at each new fedora kernel
>> release because the versionning seems to not follow standards :
>> http://rt2x00.serialmonkey.com/phpBB2/viewtopic.php?t=2965
>>
>> What do you think about this ?
>>
>> Someone have similar problems with other modules ?
> This one is going all the way up to Linus since apparently he prefers
> the current naming. See
> http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20070111
> for the glorious details.
>
> Rahul
>
Ok but my problem is not really the kernel name but how a driver can
detect correctly the kernel version and eventually the backported patch
to compile fine ...
Yes. The name of the kernel is directly related to that issue.
Rahul
5:19 p.m.
>>>> "TE" == Tanguy Eric
<eric.tanguy(a)univ-nantes.fr> writes:
TE> http://rt2x00.serialmonkey.com/phpBB2/viewtopic.php?t=2965
Blah, blah, only breaks on Fedora, blah blah, Fedora people don't know
how to behave.
So exactly what is it that Fedora is doing wrong here?
- J<
6:12 p.m.
On Mon, Jan 22, 2007 at 05:19:24PM -0600, Jason L Tibbitts III wrote:
>>>>> "TE" == Tanguy Eric
<eric.tanguy(a)univ-nantes.fr> writes:
TE> http://rt2x00.serialmonkey.com/phpBB2/viewtopic.php?t=2965
Blah, blah, only breaks on Fedora, blah blah, Fedora people don't know
how to behave.
So exactly what is it that Fedora is doing wrong here?
The problem is that the rt2x00 driver assumes that there is an API
difference between kernels < 2.6.20 and >= 2.6.20. In truth there is
no guarantee of a stable API at all in Linux, and that keying off
LINUX_VERSION_CODE is next to useless. If you patch the kernel at
all, what version does it become? Perhaps one API changed to be like
Linus' 2.6.20 due to your patch(es), but another API didn't change and
is still like Linus' 2.6.19. An out-of-tree driver that keys off
LINUX_VERSION_CODE can never get this right. You could change the
version code to fix one out-of-tree driver, but then that breaks the
other.
6:19 p.m.
>>>> "CA" == Chuck Anderson <cra(a)WPI.EDU>
writes:
CA> The problem is that the rt2x00 driver assumes that there is an API
CA> difference between kernels < 2.6.20 and >= 2.6.20.
I understand that. What I don't understand is what Fedora is
supposedly doing wrong.
It's not uncommon to see various people denigrating Fedora because it
supposedly does something improper and breaks some piece of software.
Generally this is because of the fast pace of development and because
Fedora tends to pick up new bits like kernels and gcc releases before
other distros. But occasionally you see the blather that was in the
previously linked forum thread, where Fedora is denigrated for doing
something, but nobody bothers to indicate just what it is doing or why
it is wrong.
I gather that someone wants the FC6 kernel to somehow identify itself
as 2.6.20, even though it's not 2.6.20. It's a reasonable point of
discussion when the topic is the release candidates, but here we're
talking about 2.6.19 + bugfixes.
- J<
7:53 p.m.
On Mon, Jan 22, 2007 at 05:19:24PM -0600, Jason L Tibbitts III wrote:
>>>>> "TE" == Tanguy Eric
<eric.tanguy(a)univ-nantes.fr> writes:
TE> http://rt2x00.serialmonkey.com/phpBB2/viewtopic.php?t=2965
Blah, blah, only breaks on Fedora, blah blah, Fedora people don't know
how to behave.
So exactly what is it that Fedora is doing wrong here?
Unless the comment in this link is wrong:
http://rt2x00.serialmonkey.com/phpBB2/posting.php?mode=quote&p=18456&...
There is a bug in the driver anyway.
Theoretically though, the driver is trying to use LINUX_VERSION_CODE to
determine if the kernel version is 2.6.20 or greater so it can use struct
work. The fedora kernel is 2.6.20-rc(something), but it munges the kernel
version to be 2.6.19.
If the driver were upstream, this wouldn't be an issue because such version
checks wouldn't even be present.
josh
7:57 p.m.
On Mon, Jan 22, 2007 at 07:12:29PM -0500, Chuck Anderson wrote:
On Mon, Jan 22, 2007 at 05:19:24PM -0600, Jason L Tibbitts III
wrote:
> >>>>> "TE" == Tanguy Eric
<eric.tanguy(a)univ-nantes.fr> writes:
>
> TE> http://rt2x00.serialmonkey.com/phpBB2/viewtopic.php?t=2965
>
> Blah, blah, only breaks on Fedora, blah blah, Fedora people don't know
> how to behave.
>
> So exactly what is it that Fedora is doing wrong here?
The problem is that the rt2x00 driver assumes that there is an API
difference between kernels < 2.6.20 and >= 2.6.20. In truth there is
no guarantee of a stable API at all in Linux, and that keying off
LINUX_VERSION_CODE is next to useless. If you patch the kernel at
all, what version does it become? Perhaps one API changed to be like
Linus' 2.6.20 due to your patch(es), but another API didn't change and
is still like Linus' 2.6.19. An out-of-tree driver that keys off
LINUX_VERSION_CODE can never get this right. You could change the
version code to fix one out-of-tree driver, but then that breaks the
other.
Exactly. This is something external driver maintainers just have to deal
with if their driver isn't upstream¹.
josh
¹ Have is said the word "upstream" enough in this thread? No? Repeat after
me... "Upstream, Upstream, it's our way. Upstream, Upstream anything else
will ruin your day."²
² I apologize for my crappy cheer.
8:58 p.m.
On Mon, Jan 22, 2007 at 07:53:49PM -0600, Josh Boyer wrote:
Theoretically though, the driver is trying to use LINUX_VERSION_CODE
to
determine if the kernel version is 2.6.20 or greater so it can use struct
work. The fedora kernel is 2.6.20-rc(something), but it munges the kernel
version to be 2.6.19.
Sorry, ignore this part. I missed that the specific problem was talking
about FC-6.
josh
1:56 a.m.
Rahul Sundaram wrote:
Tanguy Eric wrote:
> Le mardi 23 janvier 2007 à 03:13 +0530, Rahul Sundaram a écrit :
>> Tanguy Eric wrote:
>>> I sent this message to fedora-list(a)redhat.com but i had no reaction
>>> so i
>>> try also the devel one because i find this is problem we have to solve
>>> for the core and extras merge, no ?
>>>
>>> I'm tired to have problems with rt2500 driver at each new fedora kernel
>>> release because the versionning seems to not follow standards :
>>> http://rt2x00.serialmonkey.com/phpBB2/viewtopic.php?t=2965
>>>
>>> What do you think about this ?
>>>
>>> Someone have similar problems with other modules ?
>> This one is going all the way up to Linus since apparently he prefers
>> the current naming. See
>> http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20070111
>> for the glorious details.
>>
>> Rahul
>>
> Ok but my problem is not really the kernel name but how a driver can
> detect correctly the kernel version and eventually the backported patch
> to compile fine ...
Yes. The name of the kernel is directly related to that issue.
Rahul
Besides, of course, the fact that different distros, which even may use
the same naming conventions, includes a batch of dissimilar patches and
.config options.
Determining from a version-number alone, which of a few patch will apply
cleanly to any non-vanilla kernel is virtually impossible.
/Thomas
1:59 a.m.
New subject: OT: Re: kernel versionning problem
Josh Boyer wrote:
On Mon, Jan 22, 2007 at 07:12:29PM -0500, Chuck Anderson wrote:
> On Mon, Jan 22, 2007 at 05:19:24PM -0600, Jason L Tibbitts III wrote:
>>>>>>> "TE" == Tanguy Eric
<eric.tanguy(a)univ-nantes.fr> writes:
>> TE> http://rt2x00.serialmonkey.com/phpBB2/viewtopic.php?t=2965
>>
>> Blah, blah, only breaks on Fedora, blah blah, Fedora people don't know
>> how to behave.
>>
>> So exactly what is it that Fedora is doing wrong here?
> The problem is that the rt2x00 driver assumes that there is an API
> difference between kernels < 2.6.20 and >= 2.6.20. In truth there is
> no guarantee of a stable API at all in Linux, and that keying off
> LINUX_VERSION_CODE is next to useless. If you patch the kernel at
> all, what version does it become? Perhaps one API changed to be like
> Linus' 2.6.20 due to your patch(es), but another API didn't change and
> is still like Linus' 2.6.19. An out-of-tree driver that keys off
> LINUX_VERSION_CODE can never get this right. You could change the
> version code to fix one out-of-tree driver, but then that breaks the
> other.
Exactly. This is something external driver maintainers just have to deal
with if their driver isn't upstream¹.
josh
¹ Have is said the word "upstream" enough in this thread? No? Repeat after
me... "Upstream, Upstream, it's our way. Upstream, Upstream anything else
will ruin your day."²
² I apologize for my crappy cheer.
Not crappy, but spot on ;-D
/Thomas
7:14 a.m.
mån 2007-01-22 klockan 19:12 -0500 skrev Chuck Anderson:
keying off LINUX_VERSION_CODE is next to useless. If you patch the
kernel at all, what version does it become?
Yeah... I maintain (outside Fedora) a set of packages of the Arla AFS
client, and me and the upstream developer came to the conclusion that
upstream should just target the latest vanilla kernels and then I do any
Fedora kernel related patching in the rpms. It seems like the most sane
way to deal with this kind of problem.
(And it would be nice to see the code in the kernel, but there are
problems with that too, sadly... It might be doable though.)
/abo
1:35 p.m.
On Mon, Jan 22, 2007 at 11:04:37PM +0100, Tanguy Eric wrote:
Le mardi 23 janvier 2007 à 03:13 +0530, Rahul Sundaram a écrit :
> Tanguy Eric wrote:
> > I sent this message to fedora-list(a)redhat.com but i had no reaction so i
> > try also the devel one because i find this is problem we have to solve
> > for the core and extras merge, no ?
> >
> > I'm tired to have problems with rt2500 driver at each new fedora kernel
> > release because the versionning seems to not follow standards :
> > http://rt2x00.serialmonkey.com/phpBB2/viewtopic.php?t=2965
> >
> > What do you think about this ?
> >
> > Someone have similar problems with other modules ?
>
> This one is going all the way up to Linus since apparently he prefers
> the current naming. See
> http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20070111
> for the glorious details.
>
Ok but my problem is not really the kernel name but how a driver can
detect correctly the kernel version and eventually the backported patch
to compile fine ...
There is no backported patch here. It's a bug in the rt2500 driver
that caused the same definition to be repeated twice.
The kernel version macro is reporting exactly the same thing in a Fedora
kernel as it would if it were run against a vanilla upstream kernel.org 2.6.19.2 tree.
Dave
--
http://www.codemonkey.org.uk
1:48 p.m.
On Tue, Jan 23, 2007 at 03:43:51AM +0530, Rahul Sundaram wrote:
Tanguy Eric wrote:
> Le mardi 23 janvier 2007 à 03:13 +0530, Rahul Sundaram a écrit :
>> Tanguy Eric wrote:
>>> I sent this message to fedora-list(a)redhat.com but i had no reaction so i
>>> try also the devel one because i find this is problem we have to solve
>>> for the core and extras merge, no ?
>>>
>>> I'm tired to have problems with rt2500 driver at each new fedora kernel
>>> release because the versionning seems to not follow standards :
>>> http://rt2x00.serialmonkey.com/phpBB2/viewtopic.php?t=2965
>>>
>>> What do you think about this ?
>>>
>>> Someone have similar problems with other modules ?
>> This one is going all the way up to Linus since apparently he prefers
>> the current naming. See
>> http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20070111
>> for the glorious details.
>>
>> Rahul
>>
> Ok but my problem is not really the kernel name but how a driver can
> detect correctly the kernel version and eventually the backported patch
> to compile fine ...
Yes. The name of the kernel is directly related to that issue.
No, it isn't.
The results of the macro being checked by out of tree drivers doesn't
take into consideration point releases, so it reports 2.6.19 on 2.6.19.2
just like it does on an upstream kernel (unsurprising, as we don't change it).
This is not a Fedora problem, but a problem in the code of the out
of tree driver.
(14:44:19:davej@gelk:19.2)$ cat include/linux/version.h
#define LINUX_VERSION_CODE 132627
#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))
(14:45:42:davej@gelk:linux-2.6.19.noarch)$ cat include/linux/version.h
#define LINUX_VERSION_CODE 132627
#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))
Now, it *should* be changed to support the 4th sublevel, but doing so
would probably break a ton of out of tree drivers, and would probably
be seen as another problem of "Fedora developers making kernels that don't
conform to standards".
If this change were to happen, *then* it would be a problem
that we ship 2.6.19.2 yet call it 2.6.19, but given that upstream
is broken, we are no moreso.
It's way easier to hide incompetence when there's someone else to blame,
but in this case, we're doing absolutely nothing wrong.
Dave
--
http://www.codemonkey.org.uk
1:50 p.m.
On Mon, Jan 22, 2007 at 07:53:49PM -0600, Josh Boyer wrote:
On Mon, Jan 22, 2007 at 05:19:24PM -0600, Jason L Tibbitts III
wrote:
> >>>>> "TE" == Tanguy Eric
<eric.tanguy(a)univ-nantes.fr> writes:
>
> TE> http://rt2x00.serialmonkey.com/phpBB2/viewtopic.php?t=2965
>
> Blah, blah, only breaks on Fedora, blah blah, Fedora people don't know
> how to behave.
>
> So exactly what is it that Fedora is doing wrong here?
Unless the comment in this link is wrong:
http://rt2x00.serialmonkey.com/phpBB2/posting.php?mode=quote&p=18456&...
There is a bug in the driver anyway.
Theoretically though, the driver is trying to use LINUX_VERSION_CODE to
determine if the kernel version is 2.6.20 or greater so it can use struct
work. The fedora kernel is 2.6.20-rc(something), but it munges the kernel
version to be 2.6.19.
That's true for rawhide, however this bug is about fc6, which is 2.6.19.2
Dave
--
http://www.codemonkey.org.uk
1:51 p.m.
On Mon, Jan 22, 2007 at 08:58:03PM -0600, Josh Boyer wrote:
On Mon, Jan 22, 2007 at 07:53:49PM -0600, Josh Boyer wrote:
> Theoretically though, the driver is trying to use LINUX_VERSION_CODE to
> determine if the kernel version is 2.6.20 or greater so it can use struct
> work. The fedora kernel is 2.6.20-rc(something), but it munges the kernel
> version to be 2.6.19.
Sorry, ignore this part. I missed that the specific problem was talking
about FC-6.
Likewise, ignore my retort, the horrors of processing two week long backlogs serially :)
Dave
--
http://www.codemonkey.org.uk
6319
days inactive
6325
days old
18 comments
8 participants
participants (8)
-
Alexander Boström -
Chuck Anderson -
Dave Jones -
Eric Tanguy -
Jason L Tibbitts III -
Josh Boyer -
Rahul Sundaram -
Thomas M Steenholdt