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

Date:	Sat, 3 Sep 2011 03:39:39 +0200
From:	Michał Mirosław <mirqus@...il.com>
To:	Ben Hutchings <bhutchings@...arflare.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.

W dniu 2 września 2011 23:34 użytkownik Ben Hutchings
<bhutchings@...arflare.com> napisał:
> 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.

I assume that device-specific flags won't ever be included in
vlan_features not be transferred in other ways to bridge or bonding.
If this holds, then it doesn't really matter how the flags are stored
and if they are included in features. I'll make a PoC implementation
to show the idea only after the feature cleanup is done, as otherwise
I would have yet another idea hanging in the queue.

Rough sketch is that there would be some number of bits in features
left after all global ones that drivers would present to userspace by
appending feature names to the string set returned for
ETH_SS_FEATURES. Those names would need to have common prefix like
'priv-' or maybe driver name prepended, and be documented as not
something that shoud be regarded as stable.

Best Regards,
Michał Mirosław
--
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