[PATCH v5 00/22] Tagged VLAN support

[michael-dev]

Hi,

Am 23.11.2013 23:19, schrieb Jouni Malinen:
> If you want to get this in, you will need to clean this up to
> match coding style in hostapd

you don't have any coding style documentation or hint on your website or 
in the git repo and are asking me to adhere to coding style?
I don't see how to comply with a coding style that is undocumented.

> and to merge the patches to make sense.
> hostapd and wpa_supplicant need to compile between each individual 
> patch in the
> set. There is no point in splitting the use-new-VLAN-data-type into
> close to ten patches.

you are constantly telling that if a patch is too big for the 
mailinglist, the developer should split it into smaller parts.
I was asking about this before as not using a typedef + 
always-compilation-constraint makes this thing difficult and didn't get 
a clear reply, additionally I don't get the point in merging those 
patches and then not getting it on the mailing list as you were telling 
you'd merge them.

> src/common/vlan.c is odd location for the new file
> since it is really very much specific to AP mode (src/ap/vlan.c would 
> be
> better location).

you asked src/common/vlan.h to drop the inline keyword, so using 
src/common/vlan.c is logical.
Additionally, parts of the code used by wpa_supplicant has vlan_id 
arguments, so non-AP-code references this as well.

> but always ended up in the same state where something did not make
> sense and had to stop after considerable amount of work.

as long as you don't tell me what is difficult to understand, I can't 
change it.

> I'm not going to do that again, so until there is a small and clean
> set of patches that provide reasonable change, I will have to ignore
> these. Feel free to keep the full set available somewhere, but just
> sent couple of patches at a time to the mailing list until those get
> committed.

so you want a struct vlan_description + all references changed + access 
helpers + a use case in a single, small and easy-to-review change that 
fits the mailinglist size constraint, but don't like the small quirk I 
started with using virtual vlan ids (i.e. vlan_id > 4096 referenced some 
tagging combination).

You could as well ask me the to perform a miracle. I'll not try that, I 
don't have any magic power.

If somebody else likes this feature and has the required skills, he or 
she should feel free rework the changes.

Regards,
  M. Braun