* Alexey Suslikov <alexey.susli...@gmail.com> [2014-04-21 13:13]: > Henning Brauer <lists-openbsdtech <at> bsws.de> writes: > > congratulations, that is close to unauditable. > > i put the vlan and the !vlan case next to each other ON PURPOSE. both > > cases add an ethernet header, one with a few extra fields, one > > without. Having that next to each other makes it f***ing obvious both > > cases are identical, except the vlan case filling the 3 extra fields. > Another approach is to use delayed pattern (like you did for cksums): > compute flags, a set of header assembly conditions, and, later on, keep > method call logic obvious using that flags.
I must admit I am getting tired of all these "good proposals/ideas". don't you think we've gone thru this before? 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'm even going so far as claiming this isn't even a layering violation (of which we have MANY, usually for very good reasons) since vlan is an integral part of ethernet and not stacked on top. it's not like it'd be vlan header - ethernet header - payload it actually is slightly extended ethernet header - payload or if you wish, could be expressed as ethernet header w/ etype vlan - vlan tag, prio, inside etype - payload but the latter is not how it is implemented. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services GmbH, http://bsws.de, Full-Service ISP Secure Hosting, Mail and DNS Services. Dedicated Servers, Root to Fully Managed Henning Brauer Consulting, http://henningbrauer.com/
