netdev - Re: bridge: HSR support

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:	Wed, 7 Dec 2011 00:23:21 +0100
From:	Arvid Brodin <arvid.brodin@...a.com>
To:	Stephen Hemminger <shemminger@...tta.com>
CC:	<netdev@...r.kernel.org>
Subject: Re: bridge: HSR support

Stephen Hemminger wrote:
> On Fri, 28 Oct 2011 17:34:18 +0200
> Arvid Brodin <arvid.brodin@...a.com> wrote:
> 
>> Ok, so after a lot of reading and looking through code I have this idea of a
>> standalone solution:
>>
>> 1) Add ioctls to create (and remove) "hsr" netdevs which encapsulates two
>>    physical Ethernet interfaces each (somewhat like the bridge code does, but
>>    with precisely 2 interfaces slaved).
> 
> Please use the newer netlink interface and the master attribute for this
> rather than inventing yet another ioctl.

Is the rtnl interface documented anywhere (the usage of the different IFLA_
flags etc.)? Specifically: how do I use the IFLA_MASTER flag (what's the
meaning of the 32-bit data it wants, and how is it used by the kernel)? I 
haven't been very successful figuring this out by looking at the kernel code.

Also, how do I best tell the kernel which my slave devices are when creating
the hsr device? Should I create my own IFLA_HSR_UNSPEC, etc, or can I use some
of the generic flags?

Oh, and the kernel (struct rtnl_link_ops).newlink method has two (struct
nlattr *[]) params: tb and data. What are their roles?

-- 
Arvid Brodin
Enea Services Stockholm AB
--
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