public inbox for netdev@vger.kernel.org 
 help / color / mirror / Atom feed
From: Stephen Hemminger <shemminger@vyatta•com>
To: John Fastabend <john.r.fastabend@intel•com>
Cc: davem@davemloft•net, netdev@vger•kernel.org
Subject: Re: [PATCH net-next 1/8] bridge: bridge port parameters over netlink
Date: Wed, 31 Oct 2012 14:30:20 -0700	[thread overview]
Message-ID: <20121031143020.62e08062@s6510.linuxnetplumber.net> (raw)
In-Reply-To: <50912F4D.2090602@intel.com>

On Wed, 31 Oct 2012 07:01:49 -0700
John Fastabend <john.r.fastabend@intel•com> wrote:

> On 10/29/2012 5:57 PM, Stephen Hemminger wrote:
> > Expose bridge port parameters over netlink. By switching
> > from a single byet to a nested message, this can be used for
> > other bridge parameters.
> >
> > Although, this changes IFLA_PROTINFO attribute from one byte to a full nested
> > set of attributes; it is safe for applications because the
> > old message used IFLA_PROTINFO and new one uses
> >   IFLA_PROTINFO | NLA_F_NESTED.
> >
> > The code still accepts to old format requests, and therefore stays
> > compatiable with user mode RSTP daemon. Since the type field
> > for nested and unnested attributes are different, and the old
> > code in libnetlink doesn't do the mask, it is also safe to use
> > with old versions of bridge monitor command.
> >
> > Note: although mode is only a boolean, treating it as a
> > full byte since in the future someone will probably want to add more
> > values (like macvlan has).
> >
> > Signed-off-by: Stephen Hemminger<shemminger@vyatta•com>
> >
> > ---
> 
> Stephen,
> 
> Did you see these two patches
> 
> http://patchwork.ozlabs.org/patch/193900/
> http://patchwork.ozlabs.org/patch/193901/
> 
> here I added nested bridge attributes to IFLA_AF_SPEC and pass them down
> to the drivers as needed. Should we merge these two sets so that we have
> only a single nested set of bridge attributes? Either in IFLA_AF_SPEC or
> IFLA_PROTINFO.
> 
> The attributes in this patch are port specifics and the one in the
> patches listed above are bridge specific so in this sense perhaps
> its OK to keep them separate. I'm not sure it matters much either
> way but thought I would mention it.
> 
> Also I suspect these two series will have conflicts but I haven't tried
> yet.
> 
> Thanks,
> John

This is an area where there is no clear choice.
I would like to keep AF_UNSPEC for non-protocol stuff,
that is why I targeted PF_BRIDGE:IFLA_PROTINFO.

Other alternative would be to add sysctl which is less message
based, but is more general. (ie. /default and /all are available).

  reply	other threads:[~2012-10-31 21:30 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-30  0:57 [PATCH net-next 0/8] bridge: new security features Stephen Hemminger
2012-10-30  0:57 ` [PATCH net-next 1/8] bridge: bridge port parameters over netlink Stephen Hemminger
2012-10-30 18:48   ` Tommy S. Christensen
2012-10-30 21:00     ` Stephen Hemminger
2012-10-31 14:01   ` John Fastabend
2012-10-31 21:30     ` Stephen Hemminger [this message]
2012-11-01  1:33       ` John Fastabend
2012-10-30  0:57 ` [PATCH net-next 2/8] bridge: add template for bridge port flags Stephen Hemminger
2012-10-30  0:57 ` [PATCH net-next 3/8] bridge: implement BPDU blocking Stephen Hemminger
2012-10-31  2:38   ` Cong Wang
2012-10-31 20:57     ` Stephen Hemminger
2012-10-30  0:57 ` [PATCH net-next 4/8] bridge: add root port blocking Stephen Hemminger
2012-10-30  0:57 ` [PATCH net-next 5/8] bridge: add bpdu filter Stephen Hemminger
2012-10-30  0:57 ` [PATCH net-next 6/8] tun: implement byte queue limits Stephen Hemminger
2012-10-30  1:09   ` Stephen Hemminger
2012-10-30  0:57 ` [PATCH net-next 7/8] virtio: make some structures const Stephen Hemminger
2012-10-30  1:09   ` Stephen Hemminger
2012-10-30  0:57 ` [PATCH net-next 8/8] iproute2: handle new bridge PROTINFO format Stephen Hemminger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20121031143020.62e08062@s6510.linuxnetplumber.net \
    --to=shemminger@vyatta$(echo .)com \
    --cc=davem@davemloft$(echo .)net \
    --cc=john.r.fastabend@intel$(echo .)com \
    --cc=netdev@vger$(echo .)kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox