public inbox for b.a.t.m.a.n@lists.open-mesh.org
 help / color / mirror / Atom feed
From: Andrew Lunn <andrew@lunn.ch>
To: The list for a Better Approach To Mobile Ad-hoc Networking
	<b.a.t.m.a.n@lists.open-mesh.org>
Subject: Re: [B.A.T.M.A.N.] sysfs abi documentation
Date: Sun, 9 May 2010 09:08:35 +0200	[thread overview]
Message-ID: <20100509070835.GA20977@lunn.ch> (raw)
In-Reply-To: <201005091117.05627.lindner_marek@yahoo.de>

On Sun, May 09, 2010 at 11:17:04AM +0800, Marek Lindner wrote:
> 
> Hi,
> 
> Greg asked us to provide an ABI documentation for the files creates
> in the sysfs tree. Since I am respsonsible for the sysfs stuff, I
> felt it was my turn to draft something. Please check the attachments
> and let me know whether you think we can send it or not.

> What:           /sys/class/net/<mesh_iface>/mesh/originators
> Date:           May 2010
> Contact:        Marek Lindner <lindner_marek@yahoo.de>
> Description:
>                 Displays the table of all batman nodes (in range) and
>                 the link quality towards them. Each line contains the
>                 following values:
>                   1 - originator
>                   2 - TQ (transmit quality) value of originator
>                   3 - best next hop towards originator
>                   4 - outgoing iface to reach best next hop
>                   5 - list of alternative best next hops

Hi Marek

This is something i already said in private, but i think it is going
to be a problem.

From Documentation/filesystems/sysfs.txt

  Attributes
  ~~~~~~~~~~

  Attributes can be exported for kobjects in the form of regular files in
  the filesystem. Sysfs forwards file I/O operations to methods defined
  for the attributes, providing a means to read and write kernel
  attributes.

  Attributes should be ASCII text files, preferably with only one value
  per file. It is noted that it may not be efficient to contain only one
  value per file, so it is socially acceptable to express an array of
  values of the same type. 

  Mixing types, expressing multiple lines of data, and doing fancy
  formatting of data is heavily frowned upon. Doing these things may get
  you publically humiliated and your code rewritten without notice. 

I expect that we have a problem here. My guess is some of these files
are going to have to move back into proc. Use sysfs for configuration,
where only single values are needed, and put all the tables of
originators, HNA etc back in proc where fancy formatting of data is
not frowned upon.

	Andrew


  reply	other threads:[~2010-05-09  7:08 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-09  3:17 [B.A.T.M.A.N.] sysfs abi documentation Marek Lindner
2010-05-09  7:08 ` Andrew Lunn [this message]
2010-05-09  7:20   ` Marek Lindner
2010-05-09 14:58 ` Sven Eckelmann
2010-05-09 17:44   ` Marek Lindner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100509070835.GA20977@lunn.ch \
    --to=andrew@lunn.ch \
    --cc=b.a.t.m.a.n@lists.open-mesh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox