netdev - Re: [RFC, 1/2] ethtool: Implement private flags interface for ethtool application.

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1314999272.3419.19.camel@bwh-desktop>
Date:	Fri, 02 Sep 2011 22:34:32 +0100
From:	Ben Hutchings <bhutchings@...arflare.com>
To:	Michał Mirosław <mirqus@...il.com>
Cc:	"Wyborny, Carolyn" <carolyn.wyborny@...el.com>,
	David Miller <davem@...emloft.net>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [RFC, 1/2] ethtool: Implement private flags interface for
 ethtool application.

On Fri, 2011-09-02 at 23:22 +0200, Michał Mirosław wrote:
> W dniu 2 września 2011 23:17 użytkownik Michał Mirosław
> <mirqus@...il.com> napisał:
> > 2011/9/2 Wyborny, Carolyn <carolyn.wyborny@...el.com>:
> >>>-----Original Message-----
> >>>From: David Miller [mailto:davem@...emloft.net]
> >>>Sent: Friday, September 02, 2011 1:55 PM
> >>>To: Wyborny, Carolyn
> >>>Cc: bhutchings@...arflare.com; netdev@...r.kernel.org
> >>>Subject: Re: [RFC, 1/2] ethtool: Implement private flags interface for
> >>>ethtool application.
> >>>
> >>>From: Carolyn Wyborny <carolyn.wyborny@...el.com>
> >>>Date: Fri,  2 Sep 2011 13:50:30 -0700
> >>>
> >>>> This patch completes the user space implementation of the private
> >>>> flags inteface in ethtool. Using -b/-B options.
> >>>>
> >>>> Signed-off-by: Carolyn Wyborny <carolyn.wyborny@...el.com>
> >>>
> >>>The only use case you show here is something generic which other
> >>>chips have, Energy Efficient Ethernet.
> >>>
> >>>Making an attribute private which is present widely amonst various
> >>>networking chips makes no sense at all.
> >>>
> >>>It deserved a generic ethtool flag.
> >>
> >> Fair enough on this particular feature, but does that negate the implementation suggestion altogether?  I can send an updated feature implementation for the use case using DMA Coalescing if that will help.
> > I would rather see this as an extension to ETHTOOL_[GS]FEATURES. Its
> > semantics allow easy expanding to handle device-private flags without
> > changing anything on userspace side.
> 
> BTW, After pending Intel drivers get converted to ndo_set_features and
> netdev->features get extended to 64 bits, it would also be possible to
> use some of the unused bits there for device/driver-private flags
> almost "for free".

I don't really like the idea of mixing common feature flags with
driver-specific flags.  It's likely to lead to confusion if you mix
devices with different drivers in a bridge or a bond.

Ben.

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

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