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:	Wed, 06 Jun 2007 13:42:25 +0200
From:	Patrick McHardy <>
To:	Stephen Hemminger <>
Subject: Re: [RFC RTNETLINK 04/09]: Link creation API

Stephen Hemminger wrote:
> On Wed, 06 Jun 2007 01:17:11 +0200
> Patrick McHardy <> wrote:
>>>If you want I'll extend existing bridge netlink to use these.
>>Are you talking about brige-port information or bridge device
>>configuration? So far the API is not suitable for anything that
>>currently uses IFLA_PROTINFO because the sender is not the driver
>>which created the device and doesn't use AF_UNSPEC. For bridge
>>device configuration it would certainly be nice to have, but I'm
>>not sure yet how to handle enslave operations. So far my favourite
>>idea is to add enslave/release operations to rtnl_link_ops and call
>>them when IFLA_MASTER is set (so the netlink message would look like
>>this: ifindex: eth0 master: br0 nlmsg_type: RTM_NETLINK). But I
>>haven't really thought this through yet.
> Was thinking AF_BRIDGE (we have it already so use it), and both
> add/remove bridge, and enslave/unslave device.

I think we should use two seperate families for bridge devices
and bridge ports. I'll think about the enslave operation some
more and try to add it next week.
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists