netdev - Re: [RFC][net-next-2.6 PATCH 0/2] rtnetlink: New IFLA_PORT_PROTO

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]

Message-ID: <loom.20101209T141255-700@post.gmane.org>
Date:	Thu, 9 Dec 2010 13:33:33 +0000 (UTC)
From:	Stefan Berger <stefanb@...ibm.com>
To:	netdev@...r.kernel.org
Subject: Re: [RFC][net-next-2.6 PATCH 0/2] rtnetlink: New IFLA_PORT_PROTO_* attr

Christian Benvenuti <benve <at> cisco.com> writes:

> 
> The following series add the new IFLA_PORT_PROTO_* nested
> protocol attributes to rtnetlink and it updates the enic
> driver to support them.
> 
> 01/2 - Add new protocol nested IFLA_PORT_PROTO_* attrs
> 02/2 - Update enic driver to support new IFLA_PORT_PROTO_* attrs
> 
> Signed-off-by: Christian Benvenuti <benve <at> cisco.com>
> Signed-off-by: Roopa Prabhu <roprabhu <at> cisco.com>
> Signed-off-by: David Wang <dwang2 <at> cisco.com>
> 
[...]
> 
> When the protocol nested attributes IFLA_PORT_PROTO_* will be
> populated with new sub-attributes (like the CLUSTER_UUID we would like
> to add), the user space clients will have to adapt to the new
> attribute scheme if they want to be able to see/receive the new
> attributes (like CLUSTER_UUID).
> 

I don't have a problem with these changes. Just on the libvirt level it's going
to be a lot more messy. We'll need another level of #ifdef's for when these new
attributes became available. In case they are there we should not just create
the netlink messages with the new attributes but first independently probe for
802.1Qbg and 802.1Qbh for whether lldpad or the kernel respectively saw the same
level of if_link.h include and/or support the new attributes and fall back to
using the old ones in case the probing failed. That way we can support
multi-boot installations with kernels before and after these changes or an
lldpad that doesn't support the new attributes and still give the user the
experience that the starting of the VM 'works' as before (the new kernel was
installed). I am assuming that it worked with 802.1Qbh before even though you
didn't have the CLUSTER_UUID support... Now that will probably add quite a bit
to the complexity of the code and the testing. I hope you'll submit a patch like
that to libvirt mailing list.

   Stefan

> Thanks
> /Christian
> 
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo <at> vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 

--
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