26 Aug
2009
26 Aug
'09
6:41 a.m.
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(a)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
26 Aug
26 Aug
7:54 a.m.
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
8:27 a.m.
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
8:01 a.m.
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
8:51 a.m.
On Wednesday 26 August 2009 16:01:27 Sven Eckelmann wrote:
I'm not so familiar with the iwconfig situation you seem to refer to. Could you
outline the issues ?
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 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
10:47 a.m.
New subject: [B.A.T.M.A.N.] Breaking long lines...
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. ;-)
10:52 a.m.
New subject: [B.A.T.M.A.N.] New name for batman-adv?
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
27 Aug
27 Aug
9:58 a.m.
New subject: [B.A.T.M.A.N.] New name for batman-adv?
On Wednesday 26 August 2009 18:52:34 Andrew Lunn wrote:
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
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.
7:44 p.m.
New subject: [B.A.T.M.A.N.] New name for batman-adv?
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
28 Aug
28 Aug
1:57 a.m.
New subject: [B.A.T.M.A.N.] New name for batman-adv?
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(a)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(a)lists.open-mesh.net
https://lists.open-mesh.net/mm/listinfo/b.a.t.m.a.n
3:08 a.m.
New subject: [B.A.T.M.A.N.] New name for batman-adv?
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(a)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(a)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(a)lists.open-mesh.net
https://lists.open-mesh.net/mm/listinfo/b.a.t.m.a.n 
9 Oct
9 Oct
6:57 p.m.
New subject: [B.A.T.M.A.N.] New name for batman-adv?
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
26 Aug
26 Aug
11:01 a.m.
New subject: [B.A.T.M.A.N.] Configuration interface...
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? 
27 Aug
27 Aug
1:57 p.m.
On Mit, 2009-08-26 at 16:51 +0800, Marek Lindner wrote:
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
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. ;-) 
26 Aug
26 Aug
9:19 a.m.
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
10:41 a.m.
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
6:08 p.m.
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
27 Aug
27 Aug
10:05 a.m.
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
11:10 a.m.
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
2:17 p.m.
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
4922
days inactive
4966
days old
b.a.t.m.a.n@lists.open-mesh.org
20 comments
10 participants
participants (10)
-
Andrew de Andrade -
Andrew Lunn -
Andrew Lunn -
Antoine van Gelder -
Bernd Petrovitsch -
elektra -
Linus Lüssing -
Marek Lindner -
Outback Dingo -
Sven Eckelmann