All of lore.kernel.org
 help / color / mirror / Atom feed
From: Edward Cree <ecree@solarflare.com>
To: David Miller <davem@davemloft.net>
Cc: <netdev@vger.kernel.org>, <linux-net-drivers@solarflare.com>
Subject: Re: [PATCH net-next v2 0/4] sfc: add MCDI tracing
Date: Fri, 22 May 2015 15:49:46 +0100	[thread overview]
Message-ID: <555F420A.2040104@solarflare.com> (raw)
In-Reply-To: <20150521.185210.860864581493237974.davem@davemloft.net>

On 21/05/15 23:52, David Miller wrote:
> All of this work to allocate the buffer, add messages to it, and dump it
> to some user obtainable location duplicates existing infrastructure in
> the kernel.
> Please do not do this, and instead use the kernel's existing tracing
> infrastructure to implement this.

The logging_buffer we allocate isn't there to store _messages_ for later
dumping, it's a work area for constructing a _single_ message, which is
then merely written to the system log with netif_info.  Thus, I don't see
how it would make much difference if we used (say) ftrace instead of
netif_info to ship the events to userspace.
The reason the buffer is long-lived is simply to avoid the overhead of
allocating and freeing it every MCDI call, since MCDIs are already known
to be serialised for other reasons.
Can you please further explain your objection and what you'd prefer us to
do?

  reply	other threads:[~2015-05-22 14:49 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-20 15:49 [PATCH net-next v2 0/4] sfc: add MCDI tracing Edward Cree
2015-05-20 15:49 ` [PATCH net-next 1/4] sfc: add tracing of MCDI commands Edward Cree
2015-05-20 15:50 ` [PATCH net-next 2/4] sfc: add sysfs entry to control MCDI tracing Edward Cree
2015-05-20 15:50 ` [PATCH net-next 3/4] sfc: add module parameter to enable MCDI logging on new functions Edward Cree
2015-05-20 15:50 ` [PATCH net-next 4/4] sfc: Initialise MCDI buffers to 0 on declaration Edward Cree
2015-05-21 22:52 ` [PATCH net-next v2 0/4] sfc: add MCDI tracing David Miller
2015-05-22 14:49   ` Edward Cree [this message]
2015-05-22 19:03     ` David Miller

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=555F420A.2040104@solarflare.com \
    --to=ecree@solarflare.com \
    --cc=davem@davemloft.net \
    --cc=linux-net-drivers@solarflare.com \
    --cc=netdev@vger.kernel.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.