Hi Folks
I will soon need to parse the output of batadv-vis -f json. However, its not really, json, it does not pass json validation tools. Hence i doubt i can use the standard parsing libraries.
There has been discussion similar to this recently, about alfred -r, and a proposal to change the output to make it json conforming. I would like to raise the discussion of modifying the vis output from batadv-vis.
I have a simulation system of four nodes, fully interconnected, with one double link, but is rather sort of translation table entries. The current vis output is:
{ "primary" : "02:00:00:00:12:01" } { "router" : "02:00:00:00:12:01", "neighbor" : "02:00:00:00:10:01", "label" : "1.000" } { "router" : "02:00:00:00:12:01", "neighbor" : "02:00:00:00:13:01", "label" : "1.004" } { "router" : "02:00:00:00:12:01", "neighbor" : "02:00:00:00:11:01", "label" : "1.000" } { "router" : "02:00:00:00:12:01", "gateway" : "8e:4c:88:c4:76:c5", "label" : "TT" } { "primary" : "02:00:00:30:10:01" } { "secondary" : "02:00:00:00:10:01", "of" : "02:00:00:30:10:01" } { "router" : "02:00:00:30:10:01", "neighbor" : "02:00:00:30:13:01", "label" : "1.000" } { "router" : "02:00:00:00:10:01", "neighbor" : "02:00:00:00:12:01", "label" : "1.000" } { "router" : "02:00:00:00:10:01", "neighbor" : "02:00:00:00:13:01", "label" : "1.000" } { "router" : "02:00:00:00:10:01", "neighbor" : "02:00:00:00:11:01", "label" : "1.000" } { "router" : "02:00:00:30:10:01", "gateway" : "f6:00:48:13:d3:1e", "label" : "TT" } { "primary" : "02:00:00:00:11:01" } { "router" : "02:00:00:00:11:01", "neighbor" : "02:00:00:00:10:01", "label" : "1.000" } { "router" : "02:00:00:00:11:01", "neighbor" : "02:00:00:00:12:01", "label" : "1.000" } { "router" : "02:00:00:00:11:01", "neighbor" : "02:00:00:00:13:01", "label" : "1.000" } { "router" : "02:00:00:00:11:01", "gateway" : "ee:be:f3:0f:26:66", "label" : "TT" } { "primary" : "02:00:00:00:13:01" } { "secondary" : "02:00:00:30:13:01", "of" : "02:00:00:00:13:01" } { "router" : "02:00:00:00:13:01", "neighbor" : "02:00:00:00:10:01", "label" : "1.000" } { "router" : "02:00:00:00:13:01", "neighbor" : "02:00:00:00:12:01", "label" : "1.000" } { "router" : "02:00:00:30:13:01", "neighbor" : "02:00:00:30:10:01", "label" : "1.016" } { "router" : "02:00:00:00:13:01", "neighbor" : "02:00:00:00:11:01", "label" : "1.000" } { "router" : "02:00:00:00:13:01", "gateway" : "8e:4c:77:b3:65:b4", "label" : "TT" }
My first suggestion for a conforming output would be:
[ { "primary" : "02:00:00:00:12:01", "neighbors" : [ { "router" : "02:00:00:00:12:01", "neighbor" : "02:00:00:00:10:01", "label" : "1.000" }, { "router" : "02:00:00:00:12:01", "neighbor" : "02:00:00:00:13:01", "label" : "1.004" }, { "router" : "02:00:00:00:12:01", "neighbor" : "02:00:00:00:11:01", "label" : "1.000" } ], "TT" : [ { "router" : "02:00:00:00:12:01", "gateway" : "8e:4c:88:c4:76:c5" } ] }, { "primary" : "02:00:00:30:10:01", "secondary" : [ "02:00:00:00:10:01" ], "neighbors" : [ { "router" : "02:00:00:30:10:01", "neighbor" : "02:00:00:30:13:01", "label" : "1.000" }, { "router" : "02:00:00:00:10:01", "neighbor" : "02:00:00:00:12:01", "label" : "1.000" }, { "router" : "02:00:00:00:10:01", "neighbor" : "02:00:00:00:13:01", "label" : "1.000" }, { "router" : "02:00:00:00:10:01", "neighbor" : "02:00:00:00:11:01", "label" : "1.000" } ], "TT" : [ { "router" : "02:00:00:30:10:01", "gateway" : "f6:00:48:13:d3:1e" } ] }, { "primary" : "02:00:00:00:11:01", "neighbors" : [ { "router" : "02:00:00:00:11:01", "neighbor" : "02:00:00:00:10:01", "label" : "1.000" }, { "router" : "02:00:00:00:11:01", "neighbor" : "02:00:00:00:12:01", "label" : "1.000" }, { "router" : "02:00:00:00:11:01", "neighbor" : "02:00:00:00:13:01", "label" : "1.000" } ], "TT" : [ { "router" : "02:00:00:00:11:01", "gateway" : "ee:be:f3:0f:26:66" } ] }, { "primary" : "02:00:00:00:13:01", "secondary" : [ "02:00:00:30:13:01" ], "neighbors" : [ { "router" : "02:00:00:00:13:01", "neighbor" : "02:00:00:00:10:01", "label" : "1.000" }, { "router" : "02:00:00:00:13:01", "neighbor" : "02:00:00:00:12:01", "label" : "1.000" }, { "router" : "02:00:00:30:13:01", "neighbor" : "02:00:00:30:10:01", "label" : "1.016" }, { "router" : "02:00:00:00:13:01", "neighbor" : "02:00:00:00:11:01", "label" : "1.000" } ], "TT" : [ { "router" : "02:00:00:00:13:01", "gateway" : "8e:4c:77:b3:65:b4" } ] } ]
I'm also wondering if label and gateway could have more meaningful names? TQ and host? Also, is TT the best?
I would like suggestions and comments from others with more experience with json. Is the basic structure O.K. Are there better names to use?
There is also the issue of can we change the format of the current output. Is it considered an ABI? Should I add a third format string which can be passed with -f to produce true json, and leave the old format as is, for backward compatibility?
Thanks Andrew
Hey Andrew,
On Tue, Oct 01, 2013 at 10:26:48PM +0200, Andrew Lunn wrote:
Hi Folks
I will soon need to parse the output of batadv-vis -f json. However, its not really, json, it does not pass json validation tools. Hence i doubt i can use the standard parsing libraries.
Yes, it is only JSON line-wise, but not the whole output. This output format however is the same as we have/had in the batctl JSON output which comes from the kernel (I think that was your contribution in the first place?).
Therefore I'd like to leave this old format as it is to allow communities to seamlessly switch from batctl json vis to alfred-vis.
There has been discussion similar to this recently, about alfred -r, and a proposal to change the output to make it json conforming. I would like to raise the discussion of modifying the vis output from batadv-vis.
Regarding the other discussions, I'm still waiting for new patches from Nils. ;)
I don't want to "parse" any transferred data in alfred, but we can do this for tools like alfred-vis ... And yes, the default json output is currently not JSON-compatible for binary data...
I have a simulation system of four nodes, fully interconnected, with one double link, but is rather sort of translation table entries. The current vis output is:
{ "primary" : "02:00:00:00:12:01" } { "router" : "02:00:00:00:12:01", "neighbor" : "02:00:00:00:10:01", "label" : "1.000" } { "router" : "02:00:00:00:12:01", "neighbor" : "02:00:00:00:13:01", "label" : "1.004" } { "router" : "02:00:00:00:12:01", "neighbor" : "02:00:00:00:11:01", "label" : "1.000" } { "router" : "02:00:00:00:12:01", "gateway" : "8e:4c:88:c4:76:c5", "label" : "TT" } { "primary" : "02:00:00:30:10:01" } { "secondary" : "02:00:00:00:10:01", "of" : "02:00:00:30:10:01" } { "router" : "02:00:00:30:10:01", "neighbor" : "02:00:00:30:13:01", "label" : "1.000" } { "router" : "02:00:00:00:10:01", "neighbor" : "02:00:00:00:12:01", "label" : "1.000" } { "router" : "02:00:00:00:10:01", "neighbor" : "02:00:00:00:13:01", "label" : "1.000" } { "router" : "02:00:00:00:10:01", "neighbor" : "02:00:00:00:11:01", "label" : "1.000" } { "router" : "02:00:00:30:10:01", "gateway" : "f6:00:48:13:d3:1e", "label" : "TT" } { "primary" : "02:00:00:00:11:01" } { "router" : "02:00:00:00:11:01", "neighbor" : "02:00:00:00:10:01", "label" : "1.000" } { "router" : "02:00:00:00:11:01", "neighbor" : "02:00:00:00:12:01", "label" : "1.000" } { "router" : "02:00:00:00:11:01", "neighbor" : "02:00:00:00:13:01", "label" : "1.000" } { "router" : "02:00:00:00:11:01", "gateway" : "ee:be:f3:0f:26:66", "label" : "TT" } { "primary" : "02:00:00:00:13:01" } { "secondary" : "02:00:00:30:13:01", "of" : "02:00:00:00:13:01" } { "router" : "02:00:00:00:13:01", "neighbor" : "02:00:00:00:10:01", "label" : "1.000" } { "router" : "02:00:00:00:13:01", "neighbor" : "02:00:00:00:12:01", "label" : "1.000" } { "router" : "02:00:00:30:13:01", "neighbor" : "02:00:00:30:10:01", "label" : "1.016" } { "router" : "02:00:00:00:13:01", "neighbor" : "02:00:00:00:11:01", "label" : "1.000" } { "router" : "02:00:00:00:13:01", "gateway" : "8e:4c:77:b3:65:b4", "label" : "TT" }
My first suggestion for a conforming output would be:
[ { "primary" : "02:00:00:00:12:01", "neighbors" : [ { "router" : "02:00:00:00:12:01", "neighbor" : "02:00:00:00:10:01", "label" : "1.000" }, { "router" : "02:00:00:00:12:01", "neighbor" : "02:00:00:00:13:01", "label" : "1.004" }, { "router" : "02:00:00:00:12:01", "neighbor" : "02:00:00:00:11:01", "label" : "1.000" } ], "TT" : [ { "router" : "02:00:00:00:12:01", "gateway" : "8e:4c:88:c4:76:c5" } ] }, { "primary" : "02:00:00:30:10:01", "secondary" : [ "02:00:00:00:10:01" ], "neighbors" : [ { "router" : "02:00:00:30:10:01", "neighbor" : "02:00:00:30:13:01", "label" : "1.000" }, { "router" : "02:00:00:00:10:01", "neighbor" : "02:00:00:00:12:01", "label" : "1.000" }, { "router" : "02:00:00:00:10:01", "neighbor" : "02:00:00:00:13:01", "label" : "1.000" }, { "router" : "02:00:00:00:10:01", "neighbor" : "02:00:00:00:11:01", "label" : "1.000" } ], "TT" : [ { "router" : "02:00:00:30:10:01", "gateway" : "f6:00:48:13:d3:1e" } ] }, { "primary" : "02:00:00:00:11:01", "neighbors" : [ { "router" : "02:00:00:00:11:01", "neighbor" : "02:00:00:00:10:01", "label" : "1.000" }, { "router" : "02:00:00:00:11:01", "neighbor" : "02:00:00:00:12:01", "label" : "1.000" }, { "router" : "02:00:00:00:11:01", "neighbor" : "02:00:00:00:13:01", "label" : "1.000" } ], "TT" : [ { "router" : "02:00:00:00:11:01", "gateway" : "ee:be:f3:0f:26:66" } ] }, { "primary" : "02:00:00:00:13:01", "secondary" : [ "02:00:00:30:13:01" ], "neighbors" : [ { "router" : "02:00:00:00:13:01", "neighbor" : "02:00:00:00:10:01", "label" : "1.000" }, { "router" : "02:00:00:00:13:01", "neighbor" : "02:00:00:00:12:01", "label" : "1.000" }, { "router" : "02:00:00:30:13:01", "neighbor" : "02:00:00:30:10:01", "label" : "1.016" }, { "router" : "02:00:00:00:13:01", "neighbor" : "02:00:00:00:11:01", "label" : "1.000" } ], "TT" : [ { "router" : "02:00:00:00:13:01", "gateway" : "8e:4c:77:b3:65:b4" } ] } ]
I'm also wondering if label and gateway could have more meaningful names? TQ and host? Also, is TT the best?
Hm, that is a good question. We also have the batman v with new metrics coming up, I'm not sure how to handle these (maybe Antonio has some idea?). It is not the TQ-value in the label after all, but some kind of ETX-converted value (255/TQ if i remember correctly).
Maybe we can change the names to: * for neighbors: router->nexthop * TT: "gateway" -> "client", "router" -> "node", maybe also change TT to clients?
I would like suggestions and comments from others with more experience with json. Is the basic structure O.K. Are there better names to use?
There is also the issue of can we change the format of the current output. Is it considered an ABI? Should I add a third format string which can be passed with -f to produce true json, and leave the old format as is, for backward compatibility?
As explained above, I'd like to keep the old format, so a third format string should be used. It would be nice (if possible) to consider BATMAN V at this point too to avoid adding many more formats in the future, but generally I'm okay with adding new formats.
Thanks, Simon
On Wed, Oct 02, 2013 at 03:05:48PM +0200, Simon Wunderlich wrote:
Hey Andrew,
On Tue, Oct 01, 2013 at 10:26:48PM +0200, Andrew Lunn wrote:
Hi Folks
I will soon need to parse the output of batadv-vis -f json. However, its not really, json, it does not pass json validation tools. Hence i doubt i can use the standard parsing libraries.
Yes, it is only JSON line-wise, but not the whole output. This output format however is the same as we have/had in the batctl JSON output which comes from the kernel (I think that was your contribution in the first place?).
Therefore I'd like to leave this old format as it is to allow communities to seamlessly switch from batctl json vis to alfred-vis.
Hi Simon
That is what i was expecting. So when i did the first implementation this morning, i added a new format, cjson, for conforming json. Not the best of names, but i could not think of anything better.
I don't want to "parse" any transferred data in alfred, but we can do this for tools like alfred-vis
No parsing needed, its just needs new functions to print it. RFC patch to come soon.
{ "primary" : "02:00:00:00:13:01", "secondary" : [ "02:00:00:30:13:01" ], "neighbors" : [ { "router" : "02:00:00:00:13:01", "neighbor" : "02:00:00:00:10:01", "label" : "1.000" }, { "router" : "02:00:00:00:13:01", "neighbor" : "02:00:00:00:12:01", "label" : "1.000" }, { "router" : "02:00:00:30:13:01", "neighbor" : "02:00:00:30:10:01", "label" : "1.016" }, { "router" : "02:00:00:00:13:01", "neighbor" : "02:00:00:00:11:01", "label" : "1.000" } ], "TT" : [ { "router" : "02:00:00:00:13:01", "gateway" : "8e:4c:77:b3:65:b4" } ] } ]
I'm also wondering if label and gateway could have more meaningful names? TQ and host? Also, is TT the best?
Hm, that is a good question. We also have the batman v with new metrics coming up,
I've not been following BATMAN V too well. Is it metric, or metrics? Can we simply change label to metric?
Maybe we can change the names to:
- for neighbors: router->nexthop
- TT: "gateway" -> "client", "router" -> "node", maybe also change TT to clients?
So here is what i have implemented.
# batadv-vis -f cjson [ { "primary" : "02:00:00:00:12:01", "neighbors" : [ { "router" : "02:00:00:00:12:01", "neighbor" : "02:00:00:00:10:01", "metric" : "1.000" }, { "router" : "02:00:00:00:12:01", "neighbor" : "02:00:00:00:13:01", "metric" : "1.012" }, { "router" : "02:00:00:00:12:01", "neighbor" : "02:00:00:00:11:01", "metric" : "1.000" } ], "clients" : [ { "node" : "02:00:00:00:12:01", "client" : "8e:4c:88:c4:76:c5" } ] } ]
Andrew
El 02/10/13 15:36, Andrew Lunn escribió:
On Wed, Oct 02, 2013 at 03:05:48PM +0200, Simon Wunderlich wrote:
Hey Andrew,
On Tue, Oct 01, 2013 at 10:26:48PM +0200, Andrew Lunn wrote:
Yes, it is only JSON line-wise, but not the whole output. This output format however is the same as we have/had in the batctl JSON output which comes from the kernel (I think that was your contribution in the first place?).
Therefore I'd like to leave this old format as it is to allow communities to seamlessly switch from batctl json vis to alfred-vis.
That is what i was expecting. So when i did the first implementation this morning, i added a new format, cjson, for conforming json. Not the best of names, but i could not think of anything better.
maybe jsondoc would be more explicit, as it differentiates the output from the current json(lines) format.
cheers, Nico
On Sun, Oct 06, 2013 at 10:35:36AM +0200, Nicolás Echániz wrote:
El 02/10/13 15:36, Andrew Lunn escribió:
On Wed, Oct 02, 2013 at 03:05:48PM +0200, Simon Wunderlich wrote:
Hey Andrew,
On Tue, Oct 01, 2013 at 10:26:48PM +0200, Andrew Lunn wrote:
Yes, it is only JSON line-wise, but not the whole output. This output format however is the same as we have/had in the batctl JSON output which comes from the kernel (I think that was your contribution in the first place?).
Therefore I'd like to leave this old format as it is to allow communities to seamlessly switch from batctl json vis to alfred-vis.
That is what i was expecting. So when i did the first implementation this morning, i added a new format, cjson, for conforming json. Not the best of names, but i could not think of anything better.
maybe jsondoc would be more explicit, as it differentiates the output from the current json(lines) format.
Hi Nico
Yes, i link it. Another patch version coming soon.
Thanks Andrew
On Wed, Oct 02, 2013 at 03:05:48PM +0200, Simon Wunderlich wrote:
I'm also wondering if label and gateway could have more meaningful names? TQ and host? Also, is TT the best?
Hm, that is a good question. We also have the batman v with new metrics coming up, I'm not sure how to handle these (maybe Antonio has some idea?). It is not the TQ-value in the label after all, but some kind of ETX-converted value (255/TQ if i remember correctly).
I think the ETX stuff comes from OLSR (but I don't know the details).
I agree with Simon that we should find a generic name (e.g. metric ?) but I am not sure we can represent this value in a "algorithm-generic" fashion (and maybe we don't want to).
Maybe we can change the names to:
- for neighbors: router->nexthop
- TT: "gateway" -> "client", "router" -> "node", maybe also change TT to clients?
TT is specific to the mechanism we use to announce clients. Moving to the generic "clients" could also be ok.
I would like suggestions and comments from others with more experience with json. Is the basic structure O.K. Are there better names to use?
There is also the issue of can we change the format of the current output. Is it considered an ABI? Should I add a third format string which can be passed with -f to produce true json, and leave the old format as is, for backward compatibility?
As explained above, I'd like to keep the old format, so a third format string should be used. It would be nice (if possible) to consider BATMAN V at this point too to avoid adding many more formats in the future, but generally I'm okay with adding new formats.
I have to think about what batman v may require. But I don't see snything special right now.
Cheers,
On 2013-10-02 18:01, Antonio Quartulli wrote:
On Wed, Oct 02, 2013 at 03:05:48PM +0200, Simon Wunderlich wrote:
I'm also wondering if label and gateway could have more meaningful names? TQ and host? Also, is TT the best?
Hm, that is a good question. We also have the batman v with new metrics coming up, I'm not sure how to handle these (maybe Antonio has some idea?). It is not the TQ-value in the label after all, but some kind of ETX-converted value (255/TQ if i remember correctly).
I think the ETX stuff comes from OLSR (but I don't know the details).
I agree with Simon that we should find a generic name (e.g. metric ?) but I am not sure we can represent this value in a "algorithm-generic" fashion (and maybe we don't want to).
May I suggest that the cjson output includes an entry to tell the version of the batman-algorithm?
Users might want to do different map overlays (or whatever) depending on the available metric(s).
On Thu, Oct 03, 2013 at 08:09:08AM +0200, Martin Hundebøll wrote:
On 2013-10-02 18:01, Antonio Quartulli wrote:
On Wed, Oct 02, 2013 at 03:05:48PM +0200, Simon Wunderlich wrote:
I'm also wondering if label and gateway could have more meaningful names? TQ and host? Also, is TT the best?
Hm, that is a good question. We also have the batman v with new metrics coming up, I'm not sure how to handle these (maybe Antonio has some idea?). It is not the TQ-value in the label after all, but some kind of ETX-converted value (255/TQ if i remember correctly).
I think the ETX stuff comes from OLSR (but I don't know the details).
I agree with Simon that we should find a generic name (e.g. metric ?) but I am not sure we can represent this value in a "algorithm-generic" fashion (and maybe we don't want to).
May I suggest that the cjson output includes an entry to tell the version of the batman-algorithm?
Users might want to do different map overlays (or whatever) depending on the available metric(s).
Hi Martin
I did think about that, but i'm not sure how. The cjson format is the simple bit. I can add an outer layer with more key:value pairs. Something like this:
batadv-vis -f cjson { "algorithm" : 4, "source_version" : "2013.4.0-g6b13699", "vis" : [ { "primary" : "fe:f0:00:00:04:01", "neighbors" : [ { "router" : "fe:f0:00:00:04:01", "neighbor" : "fe:f0:00:00:05:01", "metric" : "1.000" }, { "router" : "fe:f0:00:00:04:01", "neighbor" : "fe:f0:00:00:03:01", "metric" : "1.008" } ], "clients" : [ "00:00:43:05:00:04", "fe:f1:00:00:04:01" ] }, ... ] }
But how do we determine the algorithm version? For the moment it can simply be hard coded. But for version 5? Will the over-alfred format change? Will we have a "struct vis_v2" and VIS_PACKETVERSION_2 for algorithm 5?
Thanks Andrew
On Thu, Oct 03, 2013 at 10:11:24AM +0200, Andrew Lunn wrote:
May I suggest that the cjson output includes an entry to tell the version of the batman-algorithm?
Users might want to do different map overlays (or whatever) depending on the available metric(s).
Hi Martin
I did think about that, but i'm not sure how. The cjson format is the simple bit. I can add an outer layer with more key:value pairs. Something like this:
batadv-vis -f cjson { "algorithm" : 4, "source_version" : "2013.4.0-g6b13699", "vis" : [ { "primary" : "fe:f0:00:00:04:01", "neighbors" : [ { "router" : "fe:f0:00:00:04:01", "neighbor" : "fe:f0:00:00:05:01", "metric" : "1.000" }, { "router" : "fe:f0:00:00:04:01", "neighbor" : "fe:f0:00:00:03:01", "metric" : "1.008" } ], "clients" : [ "00:00:43:05:00:04", "fe:f1:00:00:04:01" ] }, ... ] }
But how do we determine the algorithm version? For the moment it can simply be hard coded. But for version 5? Will the over-alfred format change? Will we have a "struct vis_v2" and VIS_PACKETVERSION_2 for algorithm 5?
Good question. Maybe we don't really need to export the algorithm version?
In the end this information can be retrieved on the _same_ node where alfred (& vis) is running by reading the "routing_algo" (sysfs-)file. And we can assume that the entire network is running the same algorithm (otherwise neither alfred nor vis would work as all the nodes must share the same routing algorithm).
What about the source version? How did you get it from the module?
Cheers,
But how do we determine the algorithm version? For the moment it can simply be hard coded. But for version 5? Will the over-alfred format change? Will we have a "struct vis_v2" and VIS_PACKETVERSION_2 for algorithm 5?
Good question. Maybe we don't really need to export the algorithm version?
In the end this information can be retrieved on the _same_ node where alfred (& vis) is running by reading the "routing_algo" (sysfs-)file.
No, that does not work. You can run alfred on a machine without BATMAN. alfred --help says:
server mode options: -i, --interface specify the interface to listen on -b specify the batman-adv interface configured on the system (default: bat0) use 'none' to disable the batman-adv based best server selection
I'm using this "-i eth0 -b none" since my network topology has the logger on a machine which is bridged into the mesh.
What about the source version? How did you get it from the module?
It is the alfred version, not the kernel module version.
Andrew
On Thu, Oct 03, 2013 at 10:53:16AM +0200, Andrew Lunn wrote:
But how do we determine the algorithm version? For the moment it can simply be hard coded. But for version 5? Will the over-alfred format change? Will we have a "struct vis_v2" and VIS_PACKETVERSION_2 for algorithm 5?
Good question. Maybe we don't really need to export the algorithm version?
In the end this information can be retrieved on the _same_ node where alfred (& vis) is running by reading the "routing_algo" (sysfs-)file.
No, that does not work. You can run alfred on a machine without BATMAN. alfred --help says:
server mode options: -i, --interface specify the interface to listen on -b specify the batman-adv interface configured on the system (default: bat0) use 'none' to disable the batman-adv based best server selection
I'm using this "-i eth0 -b none" since my network topology has the logger on a machine which is bridged into the mesh.
Oh ok, I didn't think about this case.
What about the source version? How did you get it from the module?
It is the alfred version, not the kernel module version.
Ok (but I don't see how it can be useful)
Thanks!
What about the source version? How did you get it from the module?
It is the alfred version, not the kernel module version.
Ok (but I don't see how it can be useful)
If for some reason we need to change the format in a none backwards compatible way, it gives us a key we can use to determine what format is in use.
It is just an idea, i've no strong preference.
Andrew
b.a.t.m.a.n@lists.open-mesh.org
-
Andrew Lunn -
Antonio Quartulli -
Martin Hundebøll -
Nicolás Echániz -
Simon Wunderlich