A generic kernel compatibilty code
Luis R. Rodriguez
backporting kernel modules. It a painful job and it seems to me an
alternative is possible. If we can write generic compatibilty code for
a new routine introduced on the next kernel how about just merging it
to the kernel under some generic compat module. This would be
completey ignored by everyone using the stable kernel but can be
copied by anyone doing backport work.
So I'm thinking something as simple as a generic compat/comat.ko with
compat-2.6.32.[ch] files.
We've already backported everything needed for wireless drivers under
compat-wireless under this format down to even 2.6.25. I volunteer to
be the sucker for this if this is reasonable and given the shot to try
it.
If you would like a better idea of what I mean please check out this
git tree and check out the files under compat/*.[ch]
git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/compat-wireless-2.6.git
Things which *cannot* be backported through new defines or exported
symbols are handled manually through patches (check compat/patches/)
but no need for something like that upstream it seems.
Please let me know what you think.
Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Luis R. Rodriguez
> Everyone and their mother reinvents the wheel when it comes to
> backporting kernel modules. It a painful job and it seems to me an
> alternative is possible. If we can write generic compatibilty code for
> a new routine introduced on the next kernel how about just merging it
> to the kernel under some generic compat module. This would be
> completey ignored by everyone using the stable kernel but can be
> copied by anyone doing backport work.
>
> So I'm thinking something as simple as a generic compat/comat.ko with
> compat-2.6.32.[ch] files.
FWIW, I meant a compat-2.6.32.[ch] and compat-2.6.31.[ch] and so on.
All these would link to the compat.ko
Luis R. Rodriguez
> On Fri, Nov 20, 2009 at 12:45 PM, Luis R. Rodriguez <mcg...@gmail.com> wrote:
>> Everyone and their mother reinvents the wheel when it comes to
>> backporting kernel modules. It a painful job and it seems to me an
>> alternative is possible. If we can write generic compatibilty code for
>> a new routine introduced on the next kernel how about just merging it
>> to the kernel under some generic compat module. This would be
>> completey ignored by everyone using the stable kernel but can be
>> copied by anyone doing backport work.
>>
>> So I'm thinking something as simple as a generic compat/comat.ko with
>> compat-2.6.32.[ch] files.
>
> FWIW, I meant a compat-2.6.32.[ch] and compat-2.6.31.[ch] and so on.
> All these would link to the compat.ko
I supose this could juse be a separate tree with some generic
compat.ko module. That might work better.
Ben Hutchings
> Everyone and their mother reinvents the wheel when it comes to
> backporting kernel modules. It a painful job and it seems to me an
> alternative is possible. If we can write generic compatibilty code for
> a new routine introduced on the next kernel how about just merging it
> to the kernel under some generic compat module. This would be
> completey ignored by everyone using the stable kernel but can be
> copied by anyone doing backport work.
>
> So I'm thinking something as simple as a generic compat/comat.ko with
> compat-2.6.32.[ch] files.
>
> We've already backported everything needed for wireless drivers under
> compat-wireless under this format down to even 2.6.25.
If you think 2.6.25 is old then I don't think you understand the scale
of the problem.
OEMs still expect us to support RHEL 4 (2.6.9) and SLES 9 (2.6.5) though
the latter will probably be dropped soon. Some other vendors apparently
still need to support even 2.4 kernels!
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
Luis R. Rodriguez
<bhutc...@solarflare.com> wrote:
> On Fri, 2009-11-20 at 12:45 -0800, Luis R. Rodriguez wrote:
>> Everyone and their mother reinvents the wheel when it comes to
>> backporting kernel modules. It a painful job and it seems to me an
>> alternative is possible. If we can write generic compatibilty code for
>> a new routine introduced on the next kernel how about just merging it
>> to the kernel under some generic compat module. This would be
>> completey ignored by everyone using the stable kernel but can be
>> copied by anyone doing backport work.
>>
>> So I'm thinking something as simple as a generic compat/comat.ko with
>> compat-2.6.32.[ch] files.
>>
>> We've already backported everything needed for wireless drivers under
>> compat-wireless under this format down to even 2.6.25.
> [...]
>
> If you think 2.6.25 is old then I don't think you understand the scale
> of the problem.
>
> OEMs still expect us to support RHEL 4 (2.6.9) and SLES 9 (2.6.5) though
> the latter will probably be dropped soon. Some other vendors apparently
> still need to support even 2.4 kernels!
Heh understood. Well shouldn't this help with that then? Sure I'd love
to see the Enteprise Linux releases on 2.6.31 but that's not going to
happen right? Shouldn't this help then?
Luis
Mauro Carvalho Chehab
Em Fri, 20 Nov 2009 12:45:51 -0800
"Luis R. Rodriguez" <mcg...@gmail.com> escreveu:
> Everyone and their mother reinvents the wheel when it comes to
> backporting kernel modules. It a painful job and it seems to me an
> alternative is possible. If we can write generic compatibilty code for
> a new routine introduced on the next kernel how about just merging it
> to the kernel under some generic compat module. This would be
> completey ignored by everyone using the stable kernel but can be
> copied by anyone doing backport work.
>
> So I'm thinking something as simple as a generic compat/comat.ko with
> compat-2.6.32.[ch] files.
>
> We've already backported everything needed for wireless drivers under
> compat-wireless under this format down to even 2.6.25. I volunteer to
> be the sucker for this if this is reasonable and given the shot to try
> it.
>
We have several backport stuff at our development tree, that works for
V4L/DVB up to kernel 2.6.16 (so, up to RHEL5).
It is based on a compat.h file, plus some extra tests inside the drivers.
They are at:
http://linuxtv.org/hg/v4l-dvb
I also started working on a different approach of dynamically patching the
drivers based on some semantic rules, parsed in perl, but I hadn't enough
time to finish.
If you want to take a look, it is at:
http://linuxtv.org/hg/~mchehab/backport/
Cheers,
Mauro
John W. Linville
> On Fri, Nov 20, 2009 at 12:51 PM, Luis R. Rodriguez <mcg...@gmail.com> wrote:
> > On Fri, Nov 20, 2009 at 12:45 PM, Luis R. Rodriguez <mcg...@gmail.com> wrote:
> >> Everyone and their mother reinvents the wheel when it comes to
> >> backporting kernel modules. It a painful job and it seems to me an
> >> alternative is possible. If we can write generic compatibilty code for
> >> a new routine introduced on the next kernel how about just merging it
> >> to the kernel under some generic compat module. This would be
> >> completey ignored by everyone using the stable kernel but can be
> >> copied by anyone doing backport work.
> >>
> >> So I'm thinking something as simple as a generic compat/comat.ko with
> >> compat-2.6.32.[ch] files.
> >
> > FWIW, I meant a compat-2.6.32.[ch] and compat-2.6.31.[ch] and so on.
> > All these would link to the compat.ko
>
> I supose this could juse be a separate tree with some generic
> compat.ko module. That might work better.
This is what I would suggest for pursuing this idea. Perhaps you
could split-off from compat-wireless, then make that tree depend on
the new tree (compat-core?)...
Hth...
John
--
John W. Linville Someday the world will need a hero, and you
linv...@tuxdriver.com might be all we have. Be ready.
Luis R. Rodriguez
<linv...@tuxdriver.com> wrote:
> On Fri, Nov 20, 2009 at 12:53:51PM -0800, Luis R. Rodriguez wrote:
>> On Fri, Nov 20, 2009 at 12:51 PM, Luis R. Rodriguez <mcg...@gmail.com> wrote:
>> > On Fri, Nov 20, 2009 at 12:45 PM, Luis R. Rodriguez <mcg...@gmail.com> wrote:
>> >> Everyone and their mother reinvents the wheel when it comes to
>> >> backporting kernel modules. It a painful job and it seems to me an
>> >> alternative is possible. If we can write generic compatibilty code for
>> >> a new routine introduced on the next kernel how about just merging it
>> >> to the kernel under some generic compat module. This would be
>> >> completey ignored by everyone using the stable kernel but can be
>> >> copied by anyone doing backport work.
>> >>
>> >> So I'm thinking something as simple as a generic compat/comat.ko with
>> >> compat-2.6.32.[ch] files.
>> >
>> > FWIW, I meant a compat-2.6.32.[ch] and compat-2.6.31.[ch] and so on.
>> > All these would link to the compat.ko
>>
>> I supose this could juse be a separate tree with some generic
>> compat.ko module. That might work better.
>
> This is what I would suggest for pursuing this idea. Perhaps you
> could split-off from compat-wireless, then make that tree depend on
> the new tree (compat-core?)...
OK thanks, will try that for the next kernel.
Luis
Luis R. Rodriguez
> On Fri, Nov 20, 2009 at 1:18 PM, John W. Linville
> <linv...@tuxdriver.com> wrote:
>> On Fri, Nov 20, 2009 at 12:53:51PM -0800, Luis R. Rodriguez wrote:
>>> On Fri, Nov 20, 2009 at 12:51 PM, Luis R. Rodriguez <mcg...@gmail.com> wrote:
>>> > On Fri, Nov 20, 2009 at 12:45 PM, Luis R. Rodriguez <mcg...@gmail.com> wrote:
>>> >> Everyone and their mother reinvents the wheel when it comes to
>>> >> backporting kernel modules. It a painful job and it seems to me an
>>> >> alternative is possible. If we can write generic compatibilty code for
>>> >> a new routine introduced on the next kernel how about just merging it
>>> >> to the kernel under some generic compat module. This would be
>>> >> completey ignored by everyone using the stable kernel but can be
>>> >> copied by anyone doing backport work.
>>> >>
>>> >> So I'm thinking something as simple as a generic compat/comat.ko with
>>> >> compat-2.6.32.[ch] files.
>>> >
>>> > FWIW, I meant a compat-2.6.32.[ch] and compat-2.6.31.[ch] and so on.
>>> > All these would link to the compat.ko
>>>
>>> I supose this could juse be a separate tree with some generic
>>> compat.ko module. That might work better.
>>
>> This is what I would suggest for pursuing this idea. Perhaps you
>> could split-off from compat-wireless, then make that tree depend on
>> the new tree (compat-core?)...
>
> OK thanks, will try that for the next kernel.
I've packaged a compat.ko here:
git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/compat.git
This should be up as soon as the kernel.org synchs. The missing piece
would just be to define a common place to put the headers for
distributions who want to use external modules which want to use this
thing.
Ben Hutchings
> On Fri, Nov 20, 2009 at 1:00 PM, Ben Hutchings
> <bhutc...@solarflare.com> wrote:
> > On Fri, 2009-11-20 at 12:45 -0800, Luis R. Rodriguez wrote:
> >> Everyone and their mother reinvents the wheel when it comes to
> >> backporting kernel modules. It a painful job and it seems to me an
> >> alternative is possible. If we can write generic compatibilty code for
> >> a new routine introduced on the next kernel how about just merging it
> >> to the kernel under some generic compat module. This would be
> >> completey ignored by everyone using the stable kernel but can be
> >> copied by anyone doing backport work.
> >>
> >> So I'm thinking something as simple as a generic compat/comat.ko with
> >> compat-2.6.32.[ch] files.
> >>
> >> We've already backported everything needed for wireless drivers under
> >> compat-wireless under this format down to even 2.6.25.
> > [...]
> >
> > If you think 2.6.25 is old then I don't think you understand the scale
> > of the problem.
> >
> > OEMs still expect us to support RHEL 4 (2.6.9) and SLES 9 (2.6.5) though
> > the latter will probably be dropped soon. Some other vendors apparently
> > still need to support even 2.4 kernels!
>
> Heh understood. Well shouldn't this help with that then? Sure I'd love
> to see the Enteprise Linux releases on 2.6.31 but that's not going to
> happen right? Shouldn't this help then?
You'd really have to ask the 'enterprise' vendors whether they'd be
interested in working on some sort of shared forward-compat library. If
the library is to include a module rather than being statically linked
into each module that needs it then there can only be one instance in
the system.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
--
Luis R. Rodriguez
OK will do thanks.
> If the library is to include a module rather than being statically linked
> into each module that needs it then there can only be one instance in
> the system.
Sure, that's the idea.
Luis