Re: [B.A.T.M.A.N.] List policy for none subscribers

[Sven Eckelmann <sven.eckelmann@gmx.de>]

[-- Attachment #1: Type: Text/Plain, Size: 2133 bytes --]

> 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 interface
> similar to brctl?
How to design the kernel<->userspace interface that it doesn't end like 
wireless-tools?

> The code is however sparse clean and checkpatch only complains about a
> few lines being longer than 80 characters. Most of these are printk
> like statements.
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 
right now.
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,
	Sven

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 835 bytes --]