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
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.
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