From: "Martin Hundebøll" <martin@hundeboll.net>
To: b.a.t.m.a.n@lists.open-mesh.org
Subject: Re: [B.A.T.M.A.N.] [RFC 1/2] batman-adv: Add interface to keep stats
Date: Tue, 10 Apr 2012 13:17:28 +0200 [thread overview]
Message-ID: <4F8416C8.6010701@hundeboll.net> (raw)
In-Reply-To: <201204101405.16743.lindner_marek@yahoo.de>
On 04/10/2012 01:05 PM, Marek Lindner wrote:
> On Tuesday, April 10, 2012 13:33:11 Martin Hundebøll wrote:
>> On 04/04/2012 10:07 AM, Marek Lindner wrote:
>>> On Monday, April 02, 2012 14:48:15 Martin Hundebøll wrote:
>>>> @@ -265,6 +266,18 @@ static int vis_data_open(struct inode *inode,
>>>> struct file *file) return single_open(file, vis_seq_print_text,
>>>> net_dev);
>>>>
>>>> }
>>>>
>>>> +static int bat_stats_open(struct inode *inode, struct file *file)
>>>> +{
>>>> + struct net_device *net_dev = (struct net_device *)inode->i_private;
>>>> + return single_open(file, bat_stats_show, net_dev);
>>>> +}
>>>
>>> Did you consider using bat_priv->stats or ethtool->get_ethtool_stats() ?
>>
>> Wouldn't that require patching netdevice.h? And in that case, is there any
>> chance to get batman-adv specific counters into the generel netdev stats
>> structure?
>
> No, I did not mean we should patch netdevice.h. The kernel has traffic
> counters we might be able to re-use for our purpose. Especially
> get_ethtool_stats() allows to export custom counters to userspace.
> The kernel developers don't like duplicating existing infrastructure. At least
> we should know what the kernel offers and come up with a reasonable
> explanation why they don't help us.
Sounds like get_ethtool_stats() could do the job - I will look into that.
>>>> +static int bat_stats_clear_open(struct inode *inode, struct file *file)
>>>> +{
>>>> + struct net_device *net_dev = (struct net_device *)inode->i_private;
>>>> + return single_open(file, bat_stats_clear, net_dev);
>>>> +}
>>>
>>> How about writing 0 to the stats file resets the counters, thus avoiding
>>> a second file ?
>>
>> That is possible, but then I would have to write the debugfs-handling
>> myself, instead of using the nice macro defined in bat_debugfs.c. It's a
>> tradeoff between code size and number of files in debugfs.
>
> Alternatively, you could extend the existing macro to also set a file handler
> for writes instead of assuming only reads. :-)
Definitely an option :)
>>> If you add an ifdef around the definition here would be no need to malloc
>>> bat_stats separately, right ?
>>
>> Do we prefer IFDEFs in the definition over mallocs? (I guess so by your
>> comment). If thats the case, then no problem with me.
>
> The types.h is full of ifdefs already. It helps to keep the structs smaller
> when functionality is not compiled into the module.
As long as we agree on ifdefs. They weren't there until BLAII and DAT added them, but I don't have a problem with'em. Let's see how long this patch-set will live, as I expect to use the get_ethtool_stats(), if possible.
--
Kind Regards
Martin Hundebøll
Frederiks Allé 99A, 1.th
8000 Aarhus C
Denmark
+45 61 65 54 61
martin@hundeboll.net
next prev parent reply other threads:[~2012-04-10 11:17 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-02 12:48 [B.A.T.M.A.N.] [RFC 0/2] Create counters for measuring behaviour Martin Hundebøll
2012-04-02 12:48 ` [B.A.T.M.A.N.] [RFC 1/2] batman-adv: Add interface to keep stats Martin Hundebøll
2012-04-04 8:07 ` Marek Lindner
2012-04-10 10:33 ` Martin Hundebøll
2012-04-10 11:05 ` Marek Lindner
2012-04-10 11:17 ` Martin Hundebøll [this message]
2012-04-10 11:31 ` Marek Lindner
2012-04-02 12:48 ` [B.A.T.M.A.N.] [RFC 2/2] batman-adv: Increment stat counters on rx, tx, fwd Martin Hundebøll
2012-04-04 8:08 ` [B.A.T.M.A.N.] [RFC 0/2] Create counters for measuring behaviour Marek Lindner
2012-04-10 10:34 ` Martin Hundebøll
2012-04-10 11:08 ` Marek Lindner
2012-04-10 11:18 ` Martin Hundebøll
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=4F8416C8.6010701@hundeboll.net \
--to=martin@hundeboll.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.