...

A current vis output would be:

  "fe:fe:00:00:04:01" -> "fe:fe:00:00:05:01" [label="1.0"]
  "fe:fe:00:00:04:01" -> "fe:fe:00:00:03:01" [label="1.0"]
  "fe:fe:00:00:04:01" -> "00:ff:7c:3c:ec:e0" [label="HNA"]
  subgraph "cluster_fe:fe:00:00:04:01" {
          "fe:fe:00:00:04:01" [peripheries=2]
          "fe:fe:00:00:04:02"
  }

I suggest something like:

fe:fe:00:00:04:01 fe:fe:00:00:05:01 255 fe:fe:00:00:03:01 255 00:ff:7c:3c:ec:e0 HNA fe:fe:00:00:04:02 S

In BNF something like

<Primary MAC> <Doublets> <Doublets> ::= {<Doublet> } <Doublet> ::= <MAC> <Flag/Value> <Flag/Value> ::= <TQ_Value>|<HNA>|<Secondary> <TQ_Value> ::= uint8_t <HNA> ::= "HNA" <Secondary> ::= "S" We then have a list of these, one line per mesh node which has provided VIS information.

Couple of questions:

• Would (<TQ_Value> / 255) be equivalent to the label value in the

current vis output?

I need to look at the current code to see how it derives its value. Since you cannot use floating point in the kernel i know it does something different than plain /255. What ever it does, i would keep the same algorithm in batctl so the values stay the same. It would also be possible to add a flag to batctl to really do a floating point TQ_Value/255.

• Does <Secondary> refer to a secondary interface reachable from

<Primary MAC> ?

Linus added the subgraph for the primary and secondary interfaces.

https://lists.open-mesh.net/pipermail/b.a.t.m.a.n/2009-August/001669.html https://lists.open-mesh.net/pipermail/b.a.t.m.a.n/2009-August/001723.html

The word "secondary" is mine, i don't think Linus used it anywhere. I'm happy to change this to something else.

Looks sane!

Thanks

Andrew

So, the question is whether we want to make batctl the almighty tool that we always depend on or are we trying to find alternative solutions to avoid that dependency ?

One option for the case at hand might be debugfs (http://lwn.net/Articles/115282/). It is another filesystem which needs to be mounted seperately - there we can output whatever we want (unlike /proc). It would be possible to create virtual files for the dot draw / json / raw output (raw means the neutral format suggested by Andrew).

I personally don't like the idea of using debugfs for VIS. I would not call the mesh topology debug information for kernel hackers, which is the purpose of debugfs.

However i do see a compromise.

1) Make /proc/net/batman-adv/vis the neutral format i suggested, or something similar. Extend batctl to use this and apply formatting as wanted.

2) Add a kernel module internal interface which allows other kernel modules to get access to the raw VIS data. Write a batman-graphviz and a batman-json kernel module which outputs the VIS data in formatted text to debugfs.

If you don't want userspace dependencies, and you know your kernel supports the optional debugfs, you can use the kernel modules. If not, batctl will always work, it just requires you have a version which understands the current proc format.

Andrew