linux-embedded.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Jared Hulbert <jaredeh@gmail.com>
Cc: "David Woodhouse" <dwmw2@infradead.org>,
	carsteno@de.ibm.com, Linux-kernel@vger.kernel.org,
	linux-embedded@vger.kernel.org,
	linux-mtd <linux-mtd@lists.infradead.org>,
	"Jörn Engel" <joern@logfs.org>
Subject: Re: [PATCH 05/10] AXFS: axfs_profiling.c
Date: Thu, 21 Aug 2008 17:06:36 +0200	[thread overview]
Message-ID: <200808211706.37761.arnd@arndb.de> (raw)
In-Reply-To: <6934efce0808210755n1977e085o63b8b91e84575dc9@mail.gmail.com>

On Thursday 21 August 2008, Jared Hulbert wrote:

> 1) same mount point -
> I don't see how this works without an ioctl.  I can't just make up
> files in my mounted filesystem.   You expect the mounted version to
> match input to the mkfs.  I'd not be happy with an ioctl.  You can
> just read it.

I think what Carsten was suggesting is that you create extra files
in the file system that behave like your current procfs files.
This limits the choice for names inside of the file system, and
therefor I think should not be done.
 
> 2) sysfs -
> I agree with Carsten, I don't see how this fits in the sysfs hierarchy.

You can create attributes below the device you have mounted.
Technically possible, the main issue I see with this is having
to maintain ABI compatibility.

> 3) debugfs -
> I don't know diddly about this.
> 
> So why not /proc?

/proc has the same ABI restrictions as sysfs. We more or less stopped
allowing new files in /proc some 5 years ago for this reason. I didn't
even read beyond the word /proc to know that what you do here is wrong.
debugfs is normally easier to use than procfs as well, you just
define some file_operations with read/write callbacks and call
debugfs_create_file with the path name below /sys/kernel/debug.

If I may give yet another suggestion:

4) no profiling at all
The profiling code has certainly been useful to you during development,
and you should keep that code around for your own work on it,
but maybe you should not push that upstream, because regular users
are not going to need it.

	Arnd <><

  reply	other threads:[~2008-08-21 15:06 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-21  5:45 [PATCH 05/10] AXFS: axfs_profiling.c Jared Hulbert
2008-08-21  8:44 ` Carsten Otte
2008-08-21  8:49   ` David Woodhouse
2008-08-21 10:20     ` Carsten Otte
2008-08-21 11:39     ` Arnd Bergmann
2008-08-21 14:55       ` Jared Hulbert
2008-08-21 15:06         ` Arnd Bergmann [this message]
2008-08-21 15:17           ` Jared Hulbert
2008-08-21 15:50             ` Arnd Bergmann
2008-08-22  7:26             ` Carsten Otte
2008-08-21 15:18           ` Geert Uytterhoeven
2008-08-22 20:37         ` Arnd Bergmann
     [not found] ` <200808221840.39206.arnd@arndb.de>
     [not found]   ` <6934efce0808221037u4548dd00q9ccd67545bfbcc8@mail.gmail.com>
2008-08-22 19:38     ` Arnd Bergmann

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=200808211706.37761.arnd@arndb.de \
    --to=arnd@arndb.de \
    --cc=Linux-kernel@vger.kernel.org \
    --cc=carsteno@de.ibm.com \
    --cc=dwmw2@infradead.org \
    --cc=jaredeh@gmail.com \
    --cc=joern@logfs.org \
    --cc=linux-embedded@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.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;
as well as URLs for NNTP newsgroup(s).