Henning Brauer <lists-openbsdtech <at> bsws.de> writes: > I must admit I am getting tired of all these "good proposals/ideas". > don't you think we've gone thru this before?
Look, I haven't called them good or bad. > what you propose would require a custom vlan_output function which > does nothing but setting the flag and then calls ether_output. > what exactly is won with that? except making things less obvious? > preparing for the highly likely case that something but a vlan > interface (as in, IFT_L2VLAN) needs to add a L2VLAN ethernet header? (I understand you want code - not theoretical speculations). I assume, there is an input and output of a stack. And lot of (possible) encapsulation subsystems in the middle: vlan, vlan-in-vlan, ipsec, you name it. And if I understood your cksum plan right, being in the middle, given packet doesn't know its destiny, but different subsystems may assign tags so on the output packet may assemble itself right (by calling necessary methods) Given a number of subsystems, delayed processing (promise pattern variation, actually) is way to go, imo, because stack will have homogeneous approach for entire packet assembly logic. In terms of above pattern, right: vlan_output will only set a flag and call ether_output - this is what you already did with cksums.
