Ben Greear writes: > > I find it hard to not take it personally. Non-communication due to things slipping thru cracks is normal in Linux kernel community, unfortunately -- you have to consider some decent timeout (2-3 days), and ask again. Overworked admins can't always answer immediately, and decide to postpone something, but then the resurrection of the item gets lost under some huge pile of accumulated things... > > The code is technically correct in that it seems to cause no > > harm to existing users, and it actively provides the 802.1Q VLAN > > feature that some people like. It is *mostly* ok. Something odd is going in in the multicast, but that I haven't been able to figure out. It might be that the API for de-registering multicast MAC sets is not good enough for this type of use in the network devices - or that Ben's code for handling them is shoddy. The odd things appear only with multicast, and there only in form of not deregistering subscribed MC MACs correctly per interface. The physical card stays subscribed for MACs which none of the consumers (VLANs) are interested in. > > It has been stable for a year now (2.2 and 2.4). Every piece of > > VLAN code has #ifdef's around it, so it will not impact the kernel > > at all if it is not selected for inclusion. Your original code did touch deeply into the packet receiver main processing, and I haven't checked if you merged my changes which move that processing into VLAN-protocol receiver, instead of special treating the incoming packets with VLAN tags. /Matti Aarnio - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org
