[Top] [All Lists]

Re: [PATCH] ethtool_ops rev 4

To: Matthew Wilcox <willy@xxxxxxxxxx>
Subject: Re: [PATCH] ethtool_ops rev 4
From: Jeff Garzik <jgarzik@xxxxxxxxx>
Date: Sun, 03 Aug 2003 13:09:11 -0400
Cc: netdev@xxxxxxxxxxx
In-reply-to: <20030803145656.GI22222@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Organization: none
References: <20030801150232.GV22222@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20030801154021.GA7696@xxxxxxx> <20030801154656.GW22222@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20030801162536.GA18574@xxxxxxx> <20030802222145.GE22222@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <3F2C3C86.6000202@xxxxxxxxx> <20030803002744.GF22222@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <3F2C7E12.8070904@xxxxxxxxx> <20030803145656.GI22222@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021213 Debian/1.2.1-2.bunk
Matthew Wilcox wrote:
On Sat, Aug 02, 2003 at 11:14:26PM -0400, Jeff Garzik wrote:

Matthew Wilcox wrote:

Nothing stops it being implemented as a macro in kcompat.  Having it as
an inline function gives it argument typechecking which always gives me
the warm fuzzies.

No, it _needs_ to be a macro for maximum flexibility.

Most importantly, kcompat code may use '#ifndef SET_ETHTOOL_OPS' as a trigger, to signal that compat code is needed. No need for drivers to create tons of kernel-version-code ifdefs, just to test for when ethtool_ops appeared in 2.6, for when it starts appearing in 2.4 vendor backports, and (possibly) 2.4 itself. Also, doing it at the cpp level allows compat code to #undef it, if it _really_ knows what its doing, and the situation calls for it.

OK.  At this point, I really feel like I'm getting in the way and
hindering more than I'm helping.  Can I pass the torch to you and let
you finish the job?

Sorry to give that impression :( I think we're pretty much "there". But if you wanna hand it off to me for the last little bits, and merging, that's fine too. I'll leave it up to you.


<Prev in Thread] Current Thread [Next in Thread>