As a side issue, i'm not sure batman-adv is the right name for
mainline. In the context of the batman project, it makes sense, but
from the perspective of mainline, this is the first version of batman,
and maybe we cannot justify the advanced.
It is the name of the protocol and it
doesn't make sense to have two complete
different B.A.T.M.A.N. things with the exact name hanging around. One in the
mainline kernel and one in here for layer 3 stuff. I have also personally a
problem with the algorithm and the layer 3 protocol having the same name - but
with completely different version numbering scheme.
To the wiki stuff. The policy was long time correct if I remember it correct
(send my first stuff without being subscribed). Maybe it was accidentally
changed when the administrator upgraded the mailing list/mail stuff.
What make me a little curious is what that change would mean for the
development model. Ok, they would have to work with a git clone and have to
send merge requests/patches to upstream - but what about internal packet
versions. The current version is 7 and have it to support older version in the
(very probably) situation that the packet format is changed again?
Should /proc/net/batman-adv/interface be replaced with an IOCTL
similar to brctl?
How to design the kernel<->userspace interface that it
doesn't end like
The code is however sparse clean and checkpatch only complains about
few lines being longer than 80 characters. Most of these are printk
I found also some other things and also told that Marek - but I
think that not
everything was included in the patch I send some weeks ago. Maybe it was only
to break printk statements to fit in 80 chars per line, but I am not sure
I am relativ sure that checkpatch didn't liked the initialization of variables
on stack with NULL... which I don't agree. But I haven't checked the kernel
coding style documents yet.
And as my position as random guy I want to thank you for contacting Greg G-K
Just my two cents,