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

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

[Andrew Lunn]

Hi folks

Yesterday evening i sent an email to Greg KH about getting batman into
mainline via staging. I CCed the list. Since i used an account which is
not subscribed, i got a bounce:

  You are not allowed to post to this mailing list, and your message
  has been automatically rejected.  If you think that your messages
  are being rejected in error, contact the mailing list owner at
  b.a.t.m.a.n-owner@lists.open-mesh.net.

This is contrary to what the wiki says:

http://open-mesh.org/wiki/MailingList

  You can subscribe to our Mailing List here. You can also send an
  E-Mail without subscription to b.a.t.m.a.n@…, but note that this
  message will have to be accepted manually (and this can take some
  time).

Greg KH reply also bounced, and he was not so happy about that.

If we want to receive comments from the kernel experts, we are
probably going to need an open list.

I can think of two options:

1) Make the batman list open for none subscribers to post to.

2) Create a batman-adv list which is open and we use that for all
   discussion about kernel work.

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.

    Andrew

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

[Marek Lindner]

Hi,

> This is contrary to what the wiki says:
>
> http://open-mesh.org/wiki/MailingList
>
>   You can subscribe to our Mailing List here. You can also send an
>   E-Mail without subscription to b.a.t.m.a.n@…, but note that this
>   message will have to be accepted manually (and this can take some
>   time).

the wiki is obviously wrong here. I see 2 options:

1) Correcting the wiki.

2) Finding people that are willing to handle the moderator requests.


> 1) Make the batman list open for none subscribers to post to.

That will bring a lot of SPAM to our list. Last time I checked we got 25.000 
SPAM mails in less than 3 days. Moderator requests could be the right 
compromise if somebody deals with the requests.


> 2) Create a batman-adv list which is open and we use that for all
>    discussion about kernel work.

We always can create more mailing lists but I don't have the feeling we have 
that much traffic to justify another mailing list. Or what do you think ?


> 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.

Yeah, maybe you are right.

Regards,
Marek

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

[Sven Eckelmann]

[-- 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 --]

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

[Andrew Lunn]

> the wiki is obviously wrong here. I see 2 options:

I just thought of a third option.

Ask for a list on vger.kernel.org and use its spam filtering, which i
expect is pretty good. They seem to host some small lists. irda-users
only has 10 subscribers. linux-rdma has 9.

     Andrew

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

[Marek Lindner]

On Wednesday 26 August 2009 16:01:27 Sven Eckelmann wrote:
> 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.

You are right - the situation still is a bit messy. I think Andrew has a point 
saying that "adv" might be rejected. I even could imagine that the name 
"batman" causes some irritation. ;-)

A while back Justin Dean suggested a new name for the protocol:
stateless proactive adhoc networking protocol
Does not sound too bad in my opinion. Other opinions ?


> 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.

Yes, it was configured as described in the wiki but nobody was checking the 
moderator requests which made the problem worse as some people thought their 
mail will be handled at some point. Instead they were hanging there forever.
I just forgot to adjust the wiki.


> > 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?

I'm not so familiar with the iwconfig situation you seem to refer to. Could you 
outline the issues ?


> 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.

Yes, you found a way to break a long string into smaller pieces although I 
can't quite remember how you did it.  ;-)


> And as my position as random guy I want to thank you for contacting Greg
> G-K

Thanks from me as well! 

Regards,
Marek

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

[elektra]

Hi!

> > 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.

One problem of the B.A.T.M.A.N. project is the confusion we created by having 
too many versions. Renaming batman-advanced to batman would be the worst we 
could probably do with this regard.

> 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.

In principle a open-posting list would be nice, but I don't see this 
implemented anywhere with reason. My guess would be that no one is willing to 
go through literally thousands of SPAM mails every day to find the one 
legitimate e-mail coming in once a week that is waiting for approval by the 
list admins. Whenever I tried posting as a non-subscriber to a mailing list 
my email never went through.

> 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?

This is a good and important question. Even more so because Marek and I were 
having a initial discussion via VOIP about ideas and changes to the algorithm 
for the next generation mark 5 of the protocol algorithm. Our aim is (again) 
reduced computational and data overhead, faster convergence speed, a 
simplification of the protocol  and added support for IPv6. This step will 
again call for a higher packet version number, naturally. I guess the kernel 
developers won't be amused  to include something in the main line which is 
still under heavy development? 

We should discuss the changes to mark 5 with all the people which are deeper 
involved. It would be awesome to meet you all physically somewhere for 
a "B.A.T.M.A.N. developer meeting/conference" to set the agenda and gather 
ideas...  I could organize a venue if you want to come to Berlin...

> And as my position as random guy I want to thank you for contacting Greg
> G-K

I want to say big THANKS to all people - testers, developers - that are 
contributing to the project. Marek, Andrew, Sven, Axel, Yang, Antoine, 
Simon... - it is a great joy for me to see your contributions! 

Cheers,
Elektra

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

[Andrew Lunn]

> In principle a open-posting list would be nice, but I don't see this
> implemented anywhere with reason. My guess would be that no one is
> willing to go through literally thousands of SPAM mails every day to
> find the one legitimate e-mail coming in once a week that is waiting
> for approval by the list admins. Whenever I tried posting as a
> non-subscriber to a mailing list my email never went through.

The spam filter is important here. If you try to do it yourself, i
think you are lost. However i'm subscribed to a number of open lists:

five of the ecos-* lists hosted on sourceware.org
lirc on sourceforge
ivtv list on ivtvdriver.org
etc

It is not often i get spam on these lists. I would suggest using one
of the big well known list providers, like sourceware, sourceforge, or
vger and let it do all the hard work.

     Andrew

[B.A.T.M.A.N.] Breaking long lines...

[Andrew Lunn]

> > 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.
> 
> Yes, you found a way to break a long string into smaller pieces although I 
> can't quite remember how you did it.  ;-)

ANSI C/C++ allows:

"foor"
"bar"

and the compiler will glue the parts back together as "foobar". 

However, i often don't like the resulting code layout. I also think
there might be a bug in checkpatch. The relevant code is:

#80 column limit
                if ($line =~ /^\+/ && $prevrawline !~ /\/\*\*/ &&
                    $rawline !~ /^.\s*\*\s*\@$Ident\s/ &&
                    $line !~ /^\+\s*printk\s*\(\s*(?:KERN_\S+\s*)?"[X\t]*"\s*(?:,|\)\s*;)\s*$/ &&
                    $length > 80)
                {
                        WARN("line over 80 characters\n" . $herecurr);
                }

my perl is not good, but it appears to be looking for KERN_, eg
KERN_ERR, KERN_WARNING etc, and maybe should be ignoring such lines?

          Andrew

[B.A.T.M.A.N.] New name for batman-adv?

[Andrew Lunn]

> You are right - the situation still is a bit messy. I think Andrew has a point 
> saying that "adv" might be rejected. I even could imagine that the name 
> "batman" causes some irritation. ;-)
> 
> A while back Justin Dean suggested a new name for the protocol:
> stateless proactive adhoc networking protocol
> Does not sound too bad in my opinion. Other opinions ?

spanp

Not the nicest of acronym. It would be good to be able to build a
short, 3 letter abbreviation of the acronym for the network device
name. That is one thing that batman->bat0 has going for it.

      Andrew

[B.A.T.M.A.N.] Configuration interface...

[Andrew Lunn]

> > > 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?
> 
> I'm not so familiar with the iwconfig situation you seem to refer to. Could you 
> outline the issues ?

It is complex and horrible. It is also badly implemented by many
wireless devices so is inconsistent.

However, batman has a much simpler interface. There is a lot less to
configure:

originator interval
aggregation to enable/disable
vis server/client mode
interfaces to use

So it should be possible to implement a reasonably simple interface. I
think only the interfaces is somewhat tricky and needs thinking
about. The rest can be individual files in /sys.

       Andrew

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

[Andrew Lunn]

> This is a good and important question. Even more so because Marek and I were 
> having a initial discussion via VOIP about ideas and changes to the algorithm 
> for the next generation mark 5 of the protocol algorithm. Our aim is (again) 
> reduced computational and data overhead, faster convergence speed, a 
> simplification of the protocol  and added support for IPv6. This step will 
> again call for a higher packet version number

How many of these goals can be reached without changing the packet
format? I've implemented regenerating lost OGMs without changing the
protocol to a degree it needs to bump the version number. Does
removing the averaging of TQ from remote neighbors change the message
format?

My question would be, does not changing the message format so that the
version number can stay the same impose too high a penalty in terms of
design restrictions?

       Andrew

Re: [B.A.T.M.A.N.] New name for batman-adv?

[Marek Lindner]

On Wednesday 26 August 2009 18:52:34 Andrew Lunn wrote:
> > stateless proactive adhoc networking protocol
> > Does not sound too bad in my opinion. Other opinions ?
>
> spanp
>
> Not the nicest of acronym. It would be good to be able to build a
> short, 3 letter abbreviation of the acronym for the network device
> name. That is one thing that batman->bat0 has going for it.

Well, we safely can omit the last "p" to make it "span". 
span0 looks fine to me.  ;-)

By the way, I was referring to the protocol name and not to the 
implementation's name. Sven pointed out that the protocol and the 
implementation share the same name which is a bit confusing.

Feel free to make alternative suggestions. :-)

Regards,
Marek

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

[Marek Lindner]

On Thursday 27 August 2009 02:08:10 Andrew Lunn wrote:
> How many of these goals can be reached without changing the packet
> format? I've implemented regenerating lost OGMs without changing the
> protocol to a degree it needs to bump the version number. Does
> removing the averaging of TQ from remote neighbors change the message
> format?
>
> My question would be, does not changing the message format so that the
> version number can stay the same impose too high a penalty in terms of
> design restrictions?

Correct me if I'm mistaken but I thought you added the originator interval ?!

In the past we did not only increase the version number when the packet format 
changed. We use that number to distinguish different ways of processing routing 
information. A packet format modification is the most obvious change but not 
the only one. If I receive a packet and interprete it completely different than 
the neighbor giving that packet to me the chance of creating routing loops is 
high. Therefore any major routing protocol change might require the version 
field to be updated.

Regards,
Marek

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

[elektra]

Hi!

> How many of these goals can be reached without changing the packet
> format? I've implemented regenerating lost OGMs without changing the
> protocol to a degree it needs to bump the version number. Does
> removing the averaging of TQ from remote neighbors change the message
> format?

We were discussing about including local Hello messages in the design, so 
there will be a additional packet type. Hmm. 
Maybe we could go without breaking backward compatibility. On the other hand - 
why should we not break backward compatibility when we introduce a new 
generation of the protocol? Running old and new together may introduce 
'interesting' side effects and we'll eventually find ourself debugging 
incompatibility problems when trying to trace bugs in the new protocol 
version. Hence we have decided to add a compatibility version number in the 
packets at a very early stage of the project.

Regarding a open posting list - what would be a possible migration scenario 
for a new list hosted at sourceware et al, given that we have an existing list 
with a number of subscribers? 

Cheers,
Elektra

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

[Bernd Petrovitsch]

On Mit, 2009-08-26 at 16:51 +0800, Marek Lindner wrote:
> On Wednesday 26 August 2009 16:01:27 Sven Eckelmann wrote:
[...]
> > 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.
> 
> Yes, you found a way to break a long string into smaller pieces although I 
> can't quite remember how you did it.  ;-)

As a b.a.t.m.a.n@ lurker but kernel-ML reader (not necessarily LKML, but
the more specialized ones):
- moving the ML to vger.kernel.org was for several folks the simple way
  to open the list without the risk of daily countless spam (and there
  is next to no spam on these lists).
  Yes, the list (or another list) is than hosted elsewhere.
  But open-only-for-subscriber lists tend to be - at least - criticized
  and - IMHO probably - excluded from the MAINTAINERS file[0].
  I don't know/have no opinion on if it makes sense to make a new list
  (@vger.) primarily for the layer 2 "variant" (and it's driver
  actually).
  Current people will probably subscribe that too (and if you sort it
  into the same folder, it also looks almost like now). Perhaps the
  admins there even accept a list with to-be-subscribed email addresses
  (which makes sense for list migrations. Auto-subscribed email 
  addresses get an email anyways).
- the "80 chars per line" rule in checkpatch.pl is one of the most (if
  not *the* most) debated one. There even were requests/patches to
  simply remove that check. Or at least deactivate it per default.
  (Core) Kernel people prefer code readability over such too simple
  "technical" limits[1].
  For simple strings in "printk()"[1]: IMHO ignore the warning and
  reject patches from random people which take "checkpatch" output and
  silence it with the plain simple reason: "what exactly is it
  unreadable now?".
Disclaimer: Feel free to ignore the above (and I'm the last to decide
such issues here).

	Bernd

[0]: Accept it - it's LKML policy.
[1]: Personally it would bury the historical "80" and - in times with
     wide-screen monitors replace it with at least "132" (and I tend to
     have > 6 xterms on each virtual desktop) - at least in
     checkpatch.pl. YMMV .....
[2]: I didn't look at the source.
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services

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

[Andrew Lunn]

> Regarding a open posting list - what would be a possible migration
> scenario for a new list hosted at sourceware et al, given that we
> have an existing list with a number of subscribers?

vger is majordomo based. The current batman list is mailman. So i
doubt there is direct export/import options for all account
information. It should however to possible to simple export just the
email addresses and import them.

sourceware uses ezmlm. So again, probably no direct export/import of
everything, probably just a list of email addresses can be mass
imported.

I don't know for sourceforge. All my googles turn up the project
mailman which is hosted there, but its not clear if its what they use
for lists.

Once the list is created, the MX record for lists.open-mesh.net needs
changing to point to the new list server and the list server needs to
be configured to accept emails for that domain. This is not difficult.

Probably the best bet is to pick a list server provider and talk to
their sysadmins. I'm sure this is not the first time such an operation
has happened.

    Andrew

Re: [B.A.T.M.A.N.] New name for batman-adv?

[Andrew Lunn]

> Well, we safely can omit the last "p" to make it "span". 
> span0 looks fine to me.  ;-)

That is not so bad. A quick google search for "span linux" found:

http://www.irisa.fr/lande/genet/span/

which appears to be a user space tool to draw message sequence
charts. Its a French university project. It would be polite to ask if
they mind having a linux kernel module with the same name, just in
case they claim some sort of trademark.

Are you suggesting a mass rename: In the kernel module sources batman
or batman-adv becomes span?

   Andrew

Re: [B.A.T.M.A.N.] New name for batman-adv?

[Outback Dingo]

[-- Attachment #1: Type: text/plain, Size: 1071 bytes --]

we can do better then this, i always hated the name batman.... i remember
someone asking me, whats the protocol you use, i replied batmanand they
said, oh so your a joker huh..... i was like no seriously

SPAL2 or L2SPA   - Layer 2 stateless proactive adhoc



On Fri, Aug 28, 2009 at 2:44 AM, Andrew Lunn <andrew@lunn.ch> wrote:

> > Well, we safely can omit the last "p" to make it "span".
> > span0 looks fine to me.  ;-)
>
> That is not so bad. A quick google search for "span linux" found:
>
> http://www.irisa.fr/lande/genet/span/
>
> which appears to be a user space tool to draw message sequence
> charts. Its a French university project. It would be polite to ask if
> they mind having a linux kernel module with the same name, just in
> case they claim some sort of trademark.
>
> Are you suggesting a mass rename: In the kernel module sources batman
> or batman-adv becomes span?
>
>   Andrew
> _______________________________________________
> B.A.T.M.A.N mailing list
> B.A.T.M.A.N@lists.open-mesh.net
> https://lists.open-mesh.net/mm/listinfo/b.a.t.m.a.n
>

[-- Attachment #2: Type: text/html, Size: 1769 bytes --]

Re: [B.A.T.M.A.N.] New name for batman-adv?

[Andrew de Andrade]

[-- Attachment #1: Type: text/plain, Size: 1801 bytes --]

When I first thought of this idea before discovering this project I  
thought of the name GLIA, global lattice of interlinked appliances.  
Glia is the name for the brain cells that do all the work of  
connecting and transmitting brain messages (<http://en.wikipedia.org/wiki/Glial_cell 
 >). I'm not a big fan of the acronym I came up with based on the word  
glia. Does anyone have a better idea?

if you guys like the term Glia (or glion), you can try to come up with  
a better acronym.


On Aug 27, 2009, at 10:57 PM, Outback Dingo wrote:

> we can do better then this, i always hated the name batman....
> i remember someone asking me, whats the protocol you use, i replied  
> batman
> and they said, oh so your a joker huh..... i was like no seriously
>
> SPAL2 or L2SPA   - Layer 2 stateless proactive adhoc
>
>
>
> On Fri, Aug 28, 2009 at 2:44 AM, Andrew Lunn <andrew@lunn.ch> wrote:
> > Well, we safely can omit the last "p" to make it "span".
> > span0 looks fine to me.  ;-)
>
> That is not so bad. A quick google search for "span linux" found:
>
> http://www.irisa.fr/lande/genet/span/
>
> which appears to be a user space tool to draw message sequence
> charts. Its a French university project. It would be polite to ask if
> they mind having a linux kernel module with the same name, just in
> case they claim some sort of trademark.
>
> Are you suggesting a mass rename: In the kernel module sources batman
> or batman-adv becomes span?
>
>   Andrew
> _______________________________________________
> B.A.T.M.A.N mailing list
> B.A.T.M.A.N@lists.open-mesh.net
> https://lists.open-mesh.net/mm/listinfo/b.a.t.m.a.n
>
> _______________________________________________
> B.A.T.M.A.N mailing list
> B.A.T.M.A.N@lists.open-mesh.net
> https://lists.open-mesh.net/mm/listinfo/b.a.t.m.a.n


[-- Attachment #2: Type: text/html, Size: 2851 bytes --]

Re: [B.A.T.M.A.N.] New name for batman-adv?

[Antoine van Gelder]

On 28 Aug 2009, at 03:57 , Outback Dingo wrote:
> i replied batman and they said, oh so your a joker huh.....
> i was like no seriously
>
> SPAL2 or L2SPA   - Layer 2 stateless proactive adhoc


Why so serious ?

*grin.duck.run*

  - antoine

Re: [B.A.T.M.A.N.] New name for batman-adv?

[Linus Lüssing]

[-- Attachment #1: Type: text/plain, Size: 438 bytes --]

Hmm, I think I'd also favour SPAN routing protocol so far. Things
I came up with, were DIPD (Decentral Intelligence,
Proactive Distribution) or SIRPD (Swarm Intelligence, Proactive
Distribution) or SIMR (Swarm Intelligence Mesh Routing). I found
the discription on Wikipedia about swarm intelligence quite
fitting in this context, "[...] interacting locally [...]
very simple rules [...] no centralised control structure".

Cheers, Linus

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]