public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Artem Bityutskiy <dedekind@infradead.org>
To: Ricard Wanderlof <ricard.wanderlof@axis.com>
Cc: David Brownell <david-b@pacbell.net>,
	Kay Sievers <kay.sievers@vrfy.org>,
	Linux MTD <linux-mtd@lists.infradead.org>
Subject: Re: [patch/rfc 2.6.29 1/2] MTD: driver model updates
Date: Wed, 01 Apr 2009 10:51:46 +0300	[thread overview]
Message-ID: <1238572306.20906.42.camel@localhost.localdomain> (raw)
In-Reply-To: <Pine.LNX.4.64.0904010920570.9213@lnxricardw.se.axis.com>

On Wed, 2009-04-01 at 09:29 +0200, Ricard Wanderlof wrote:
> On Tue, 31 Mar 2009, David Brownell wrote:
> 
> > Hmm, no comments?  I had understood there was interest over on
> > the MTD side of things in exposing more information through
> > sysfs, to help avoid the need to add Even More Ioctls as part
> > of support for things like NAND chips with 4KB pages, or which
> > handle more than 4GBytes ...
> 
> I sense some ambiguity when it comes to sysfs. dwmw2 and others seem to 
> feel this is the route to go, yet no one really seems interested and the 
> only patches that people produce are for new ioctls. Admittedly, moving to 
> sysfs requires some form of high level specification before implementation 
> can be done, but still...
> 
> Could it be that the relevant interfaces would only be used, basically, 
> for mtdtools, which are quite simple in nature and an ioctl interface 
> works well. There isn't that much performance tuning to be done and not 
> very much information which humans are interested in. Most people want to 
> mount their device and go.
> 
> Indeed, from a user application perspective, sysfs seems a bit clumsy to 
> me, you have to open a file and read and write text strings (although 
> binary files are possible but, I suspect, frowned upon), rather than just 
> fire off an ioctl after filling in a struct.

On the other hand, you can easily see everything from your shell.
And in programs, it is not a big deal to write few functions which
fetch info from the sysfs files. We do this for UBI in libubi.c

Anyway, I have practical problems.

1. UBI utilities need to know sub-page size in case of NAND. And I
   have zero possibility to extend the existing ioctls. If they were
   sysfs interfaces, I would just add one more sysfs file.

2. We want to provide various statistics like count of reads, writes,
   erases. Should we create yet another ioctl for this? And for
   statistics, sysfs is just better because I can just do
   "cat /sys/class/mtd0/stats/reads_count". And I can easilly do
   this in shell scripts.

My _practical_ problems may be nicely solved with sysfs. And they are
not nicely solved with ioctls. And I am a real, existing MTD user.

-- 
Best regards,
Artem Bityutskiy (Битюцкий Артём)

  reply	other threads:[~2009-04-01  7:52 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-26  7:42 [patch/rfc 2.6.29 1/2] MTD: driver model updates David Brownell
2009-03-31 21:18 ` David Brownell
2009-03-31 23:51   ` Kay Sievers
2009-04-01 13:43     ` Juergen Beisert
2009-04-01  1:17   ` Kevin Cernekee
2009-04-01  3:21     ` David Brownell
2009-04-01  4:49       ` Kevin Cernekee
2009-04-01  6:36         ` David Brownell
2009-04-01  7:29   ` Ricard Wanderlof
2009-04-01  7:51     ` Artem Bityutskiy [this message]
2009-04-01  8:05     ` David Brownell
2009-04-01  8:25       ` Ricard Wanderlof
2009-04-01  8:28         ` Artem Bityutskiy
2009-04-02 23:41 ` Kevin Cernekee
2009-04-03  7:03   ` Artem Bityutskiy
2009-04-03  7:09     ` Artem Bityutskiy
2009-04-03 20:00     ` Kevin Cernekee
2009-04-04 14:36       ` David Woodhouse
2009-04-04 16:17         ` Kevin Cernekee
2009-04-04 16:20         ` David Brownell
2009-04-04 16:29           ` David Woodhouse
2009-04-04 17:18       ` David Brownell
2009-04-06  5:34   ` Greg KH
2009-04-03 10:04 ` David Woodhouse
2009-04-03 17:24   ` David Brownell

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=1238572306.20906.42.camel@localhost.localdomain \
    --to=dedekind@infradead.org \
    --cc=david-b@pacbell.net \
    --cc=kay.sievers@vrfy.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=ricard.wanderlof@axis.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox