From: Matthias Schiffer <mschiffer@universe-factory.net>
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.] [PATCHv2] batman-adv: fix visualization output without neighbors on the primary interface
Date: Mon, 07 May 2012 06:35:31 +0200 [thread overview]
Message-ID: <4FA75113.40401@universe-factory.net> (raw)
In-Reply-To: <20120506201435.GA27416@pandem0nium>
[-- Attachment #1: Type: text/plain, Size: 1522 bytes --]
On 05/06/2012 10:14 PM, Simon Wunderlich wrote:
> Your patch does the trick, although I think this ugly function could use a rewrite.
> First counting bytes and then allocating this size to do exactly the same thing again
> is not really good style. If you would like to volunteer to do this job (or plan to
> work more on vis), please tell me, otherwise I'll put it in on my TODO list.
While I'am already at it, I guess I can also volunteer to do some more vis work :)
Besides cleanup, are there more ideas about the vis? A nice feature I can think about would be adding some freely chosen identification string (for example the hostname) to the vis data, this could make big graphs much more readable. I wonder though if this would be possible without breaking compatiblity.
I have some questions about the code though:
- Is there any reason vis_seq_print_text() allocates a buffer at all instead of just printing the data directy into the seq_file? Looking at the seq_printf implementation, there doesn't seem to be a problem calling it while holding the lock.
- In many places in the vis code hlist_for_each_entry_rcu() is used to iterate over the hash lists, even though all access to vis_hash is guarded by the vis_hash_lock, so it seems to be okay to just use hlist_for_each_entry(). In some functions, vis_seq_print_text() being one of them, rcu_read_lock/unlock pairs could be removed as well with this change. Do I overlook something?
I'll also drop by the batman IRC channel.
Matthias
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
next prev parent reply other threads:[~2012-05-07 4:35 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-05 15:05 [B.A.T.M.A.N.] [PATCH] batman-adv: fix visualization output without neighbors on the primary interface Matthias Schiffer
2012-05-05 15:29 ` Sven Eckelmann
2012-05-05 15:49 ` Matthias Schiffer
2012-05-05 15:51 ` [B.A.T.M.A.N.] [PATCHv2] " Matthias Schiffer
2012-05-06 20:14 ` Simon Wunderlich
2012-05-07 4:35 ` Matthias Schiffer [this message]
2012-05-07 6:40 ` Marek Lindner
2012-05-07 11:10 ` Matthias Schiffer
2012-05-07 11:28 ` Sven Eckelmann
2012-05-08 6:04 ` Marek Lindner
2012-05-08 12:51 ` Matthias Schiffer
2012-05-08 20:52 ` Guido Iribarren
2012-05-09 11:33 ` Marek Lindner
2012-05-09 16:10 ` Martin Hundebøll
2012-05-10 19:47 ` Matthias Schiffer
2012-05-10 20:19 ` Marek Lindner
2012-05-10 20:46 ` Matthias Schiffer
2012-05-07 6:43 ` Sven Eckelmann
2012-05-07 6:43 ` 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=4FA75113.40401@universe-factory.net \
--to=mschiffer@universe-factory.net \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.