netdev - NET: Questions about supporting older kernel's with kmods

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <4B055479.8070101@gmail.com>
Date:	Thu, 19 Nov 2009 09:21:45 -0500
From:	Gregory Haskins <gregory.haskins@...il.com>
To:	netdev@...r.kernel.org
CC:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: NET: Questions about supporting older kernel's with kmods

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

Download attachment "signature.asc" of type "application/pgp-signature" (268 bytes)