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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 19 Dec 2014 00:35:10 +0000
From:	Thomas Graf <tgraf@...g.ch>
To:	John Fastabend <john.fastabend@...il.com>
Cc:	"Varlese, Marco" <marco.varlese@...el.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"Fastabend, John R" <john.r.fastabend@...el.com>,
	Jiri Pirko <jiri@...nulli.us>,
	"roopa@...ulusnetworks.com" <roopa@...ulusnetworks.com>,
	"sfeldma@...il.com" <sfeldma@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH net-next v3 1/1] net: Support for switch port
 configuration

On 12/18/14 at 08:03am, John Fastabend wrote:
> On 12/18/2014 07:30 AM, Varlese, Marco wrote:
> Could you also document the attributes. I think they are mostly
> clear but what is IFLA_SW_LOOPBACK. It will help later when we
> try to read the code in 6months and implement drivers.
> 
> I am thinking something like
> 
> /* Switch Port Attributes section
>  * IFLA_SW_LEARNING - turns learning on in the bridge
>  * IFLA_SW_LOOPBACK - does something interesting
> 
>  [...]
>  */

+1. I would even ask for more than that. While clear in the bridge
context, "learning" for this API targetting multi layer switches
is ambigious. The expectation towards the driver must be crystical
clear.

> >+
> >+enum {
> >+	IFLA_SW_UNSPEC,
> >+	IFLA_SW_LEARNING,
> 
> Can you address Roopa's feedback. I'm also a bit confused by the
> duplication.

Agreed. Can we decide on the ndo first and then build the APIs on
top of that? While I agree that we should have a non-bridge based
Netlink API, the underlying ndo should be the same.

> >+static const struct nla_policy ifla_sw_attr_policy[IFLA_SW_ATTR_MAX+1] = {
> >+	[IFLA_SW_LEARNING]	= { .type = NLA_U64 },
> >+	[IFLA_SW_LOOPBACK]	= { .type = NLA_U64 },
> >+	[IFLA_SW_BCAST_FLOODING] = { .type = NLA_U64 },
> >+	[IFLA_SW_UCAST_FLOODING] = { .type = NLA_U64 },
> >+	[IFLA_SW_MCAST_FLOODING] = { .type = NLA_U64 },
> >+};
> 
> Why U64 values? What would we pass in these? Are these just boolean
> bits? Maybe the annotation above will help me understand this.

I think the intent is to keep the ndo API as simple as possible
but I agree that this is wasteful. I gave this feedback on v2 already.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists