All of lore.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.com \
    --cc=davem@davemloft.net \
    --cc=john.r.fastabend@intel.com \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.