[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090109051500.GA12836@gondor.apana.org.au>
Date: Fri, 9 Jan 2009 16:15:00 +1100
From: Herbert Xu <herbert@...dor.apana.org.au>
To: Jeff Garzik <jgarzik@...ox.com>
Cc: bhutchings@...arflare.com, rick.jones2@...com, davem@...emloft.net,
netdev@...r.kernel.org
Subject: Re: [PATCH] Make possible speeds known to ethtool
On Fri, Jan 09, 2009 at 12:03:57AM -0500, Jeff Garzik wrote:
>
> I think you misunderstand. You don't have touch any drivers at all...
> see attached demonstration patch.
>
> The more general point is that it is silly to add two ethtool ioctls
> each time you want to twiddle a single boolean flag (whatever that flag
> may be, generic or driver-specific or whatnot).
>
> If you still desire separation from ->{get,set}_flags() ops, then at
> least create an ETHTOOL_[GS]STACK_FLAGS.
OK, however I'm still not convinced that this is a good idea.
First of all we don't have a shortage in the ethtool name space,
we've only used up two hex digits worth of a 32-bit integer field.
More importantly, making multiple bit changes at the same time
may create semantic nightmares in future.
For example, imagine if we started out with this generic flag
function and TX checksum offload, SG, TSO were done using it.
Now the user issues a request changing all of these bits, we'd
then have to either validate it for contradictory settings, or
devise some ad-hoc ordering in which the settings are applied.
This just seems to be unnecessary penny-pinching that doesn't
save much but may end up costing us down the road.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists