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]
Date:	Fri, 2 Sep 2011 14:35:26 -0700
From:	"Wyborny, Carolyn" <carolyn.wyborny@...el.com>
To:	Ben Hutchings <bhutchings@...arflare.com>,
	Michał Mirosław <mirqus@...il.com>
CC:	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.



>-----Original Message-----
>From: Ben Hutchings [mailto:bhutchings@...arflare.com]
>Sent: Friday, September 02, 2011 2:35 PM
>To: Michał Mirosław
>Cc: Wyborny, Carolyn; David Miller; 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.

Ok, I'll keep working on it per your previous feedback.

Thanks,

Carolyn

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ