All of lore.kernel.org
 help / color / mirror / Atom feed
From: Balbir Singh <balbir@in.ibm.com>
To: Tim Bird <tim.bird@am.sony.com>
Cc: Andrew Morton <akpm@osdl.org>, Martin Peschke <mp3@de.ibm.com>,
	linux-kernel@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: netlink vs. debugfs (was Re: [Patch 0/6] statistics infrastructure)
Date: Tue, 23 May 2006 00:04:00 +0530	[thread overview]
Message-ID: <20060522183359.GA26551@in.ibm.com> (raw)
In-Reply-To: <4471FE52.8090107@am.sony.com>

On Mon, May 22, 2006 at 11:09:22AM -0700, Tim Bird wrote:
> Andrew Morton wrote:
> > Martin Peschke <mp3@de.ibm.com> wrote:
> >> My patch series is a proposal for a generic implementation of statistics.
> > 
> > This uses debugfs for the user interface, but the
> > per-task-delay-accounting-*.patch series from Balbir creates an extensible
> > netlink-based system for passing instrumentation results back to userspace.
> > 
> > Can this code be converted to use those netlink interfaces, or is Balbir's
> > approach unsuitable, or hasn't it even been considered, or what?
> 
> Can someone give me the 20-second elevator pitch on why
> netlink is preferred over debugfs?  I've heard of a
> number of debugfs/procfs users requested to switch over.
> 
> Thanks,
>  -- Tim
> 
> =============================
> Tim Bird
> Architecture Group Chair, CE Linux Forum
> Senior Staff Engineer, Sony Electronics
> =============================

Hi, Tim,

I am no debugfs expert, I hope I can do justice to the comparison.

Debugfs						Netlink/Genetlink

1. Filesystem based - requires creating		Several types of data can
   files for each type of data passed		be multiplexed over one netlink
   down						socket.
2. Hard to determine record format/data		Contains metadata including
						type of data and length
						with each record
3. Notifications are hard			Notifications are very easy
   I think they can be done using inotify	good library support for
						notifications. Data can
						either be broadcast or
						selectively mulitcast
4. Requires several open/read/write/close	A single socket can be
   operations					opened, data from kernel
						space can be multiplexed
						over it.

I don't think I did any justice to the advantages of debugfs. The only
one I can think of is that it uses relayfs. Relayfs is efficient in the
sense that it uses per-cpu buffers.

Anybody else want to take a shot in comparing the two?

	Balbir Singh,
	Linux Technology Center,
	IBM Software Labs

  reply	other threads:[~2006-05-22 18:38 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-19 16:07 [Patch 0/6] statistics infrastructure Martin Peschke
2006-05-19 16:24 ` Andrew Morton
     [not found]   ` <661de9470605191159n75578d60qd1f3309e3a7e2234@mail.gmail.com>
2006-05-19 19:02     ` Balbir Singh
2006-05-19 23:03   ` Martin Peschke
2006-05-21 11:29     ` Balbir Singh
2006-05-22 18:09   ` netlink vs. debugfs (was Re: [Patch 0/6] statistics infrastructure) Tim Bird
2006-05-22 18:34     ` Balbir Singh [this message]
2006-05-22 18:53       ` Evgeniy Polyakov
2006-05-23 16:59   ` [Patch 0/6] statistics infrastructure Martin Peschke
2006-05-23 21:42     ` Andrew Morton
2006-05-24  3:12       ` Balbir Singh

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=20060522183359.GA26551@in.ibm.com \
    --to=balbir@in.ibm.com \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mp3@de.ibm.com \
    --cc=netdev@vger.kernel.org \
    --cc=tim.bird@am.sony.com \
    /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.