[quagga-dev 10511] Re: Adding "encapsulation dot1q" option to interfaces
bluelightning at mantech.ro
Fri May 3 00:20:46 BST 2013
I will try to do the code to be simpler as much I can. For BSD part is
very simple to program the IOCTL. In Linux with netlink/rtnetlink is
more code to be added.
My opinion the Linux netlink/rtnetlink to add the VLAN part I think that
will not be changed in the future.
In BSD maybe only if they move from IOCTL to another kernel
communication, yes the code should be rewritten. But this I think will
involve also the routing part also because I don't think that if they
change a part of kernel will change only for interfaces for example.
So there is a circle here for any angle you view.
Also for Solaris too.
But the transition from a communication to another should be done in
parallel not over the night when somebody says: from today we are using
BSD netlink communication (for example) and we drop the IOCTL.
Linux supports VLAN creating via netlink and via IOCTL. For the other
interfaces I can't say anything because I'm focus on this type of interface.
If something is going to be change in the OS I will adapt the code
properly. The functions name will be the same for all OSes. The
difference will be given by the predefined macros which are set by the
compiler and by the OS.
You said "and quagga will end up having to support these too". Like I
said: any kernel change will involve (I'm over 90% sure) also the
routing part to be changed.
Is an open source software and I've volunteered to contribute to Quagga
and improve it. And this part comparing with the rest of the Quagga code
will be a very small part which will be very easy to maintain.
Multicast is another story. I got a lot of problems to configure the
multicast between 2 different switches (Cisco and Huawei or ZTE for
example) so I don't say that was easy to make it work the code in
PS: I wish those discussion to be more focused about some productive ideas.
On 5/2/2013 11:58 PM, Nick Hilliard wrote:
> On 02/05/2013 21:36, Adrian Ban wrote:
>> Yes, indeed there are a lot of interfaces. But what is the problem adding
>> an option which can be used or not?
> If you add this functionality, the quagga code base will end up having to
> support this forever, for all future operating systems. There is support
> for linux, freebsd, netbsd, openbsd, solaris and os/x at the moment, and
> most these use either slightly or completely different semantics to handle
> vlan interfaces. It's highly likely that there will be API changes on
> these operating systems in future (just like there have been in the past),
> and quagga will end up having to support these too. From a code
> maintenance point of view, this is an unmerciful pain. Just look at the
> trouble that the various operating-system-dependent multicast interfaces
> already cause in quagga.
> also, there are more important problems to solve than this.
> Quagga-dev mailing list
> Quagga-dev at lists.quagga.net
More information about the Quagga-dev