NET: Questions about supporting older kernel's with kmods

NET: Questions about supporting older kernel's with kmods

[Gregory Haskins]

[-- Attachment #1: Type: text/plain, Size: 1165 bytes --]

Hi All,

So I was in the process of packaging up my venet driver so that it could
not only support the in-tree build (in -next), but also build as a KMP
for inclusion in existing distros that already shipped (like SLE, RHEL,
CentOS, etc).

The problem I ran into is that the ethtool and netdev_ops components of
the in-tree version do not necessarily align with the substrate
capabilities of older kernels.  What are the best-practices surrounding
this issue?

Q1) Is there any official CONFIG tags (e.g. HAVE_NETDEV_OPS) I can key
off of, or should I simply look at the kernel version?  If the latter,
any recommendation on what to use for the aforementioned features?  (I
can always try to git-annotate to figure it out, but I wonder if there
are best-practices already in place).

Q2) Is it considered "bad form" to include such compile-time directives
in the version of the code going upstream?  E.g. can my driver in -next
have "#ifdef CONFIG_HAVE_NETDEV_OPS" or other version/capability deps,
or do I need to patch these externally into the code destined for the
kmod, and leave the upstream code "pure"?

Thanks in advance,
-Greg


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 267 bytes --]

Re: NET: Questions about supporting older kernel's with kmods

[Ben Hutchings]

On Thu, 2009-11-19 at 09:21 -0500, Gregory Haskins wrote:
> Hi All,
> 
> So I was in the process of packaging up my venet driver so that it could
> not only support the in-tree build (in -next), but also build as a KMP
> for inclusion in existing distros that already shipped (like SLE, RHEL,
> CentOS, etc).
> 
> The problem I ran into is that the ethtool and netdev_ops components of
> the in-tree version do not necessarily align with the substrate
> capabilities of older kernels.  What are the best-practices surrounding
> this issue?
>
> Q1) Is there any official CONFIG tags (e.g. HAVE_NETDEV_OPS) I can key
> off of,

These feature test macros are not consistently provided.

> or should I simply look at the kernel version?

That works up to a point, but the 'enterprise' distros backport a lot to
earlier kernel versions which can make version tests invalid.

Some out-of-tree/backported drivers use autoconf-style tests, but there
is no standard way of doing this.

[...]
> Q2) Is it considered "bad form" to include such compile-time directives
> in the version of the code going upstream?
[...]

Yes.  Don't do that.

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.

Re: NET: Questions about supporting older kernel's with kmods

[Gregory Haskins]

[-- Attachment #1: Type: text/plain, Size: 1071 bytes --]

Ben Hutchings wrote:
> On Thu, 2009-11-19 at 09:21 -0500, Gregory Haskins wrote:
[...]
> 
>> or should I simply look at the kernel version?
> 
> That works up to a point, but the 'enterprise' distros backport a lot to
> earlier kernel versions which can make version tests invalid.

Good point

> 
> Some out-of-tree/backported drivers use autoconf-style tests, but there
> is no standard way of doing this.
> 

Yeah, this might be the only sane way.  It turns out that my ETHTOOL
issue was trivial.  I was missing "#include <linux/ethtool.h>" which
worked in upstream, but not in older kernels.  So that issue is resolved.

Now I just need to figure out netdev_ops.  Perhaps I will just patch the
netdev_ops out when building a kmod, since its just
a different way to describe the same thing, and the resulting driver
will perform the same.

> [...]
>> Q2) Is it considered "bad form" to include such compile-time directives
>> in the version of the code going upstream?
> [...]
> 
> Yes.  Don't do that.

Ok.

Thanks Ben,
-Greg


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 267 bytes --]