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
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.
- 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.
- 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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
b.a.t.m.a.n@lists.open-mesh.org
-
Andrew de Andrade -
Andrew Lunn -
Andrew Lunn -
Antoine van Gelder -
Bernd Petrovitsch -
elektra -
Linus Lüssing -
Marek Lindner -
Outback Dingo -
Sven Eckelmann