public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: David Brownell <david-b@pacbell.net>
To: Ricard Wanderlof <ricard.wanderlof@axis.com>
Cc: 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, 1 Apr 2009 01:05:33 -0700	[thread overview]
Message-ID: <200904010105.33674.david-b@pacbell.net> (raw)
In-Reply-To: <Pine.LNX.4.64.0904010920570.9213@lnxricardw.se.axis.com>

On Wednesday 01 April 2009, 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...

Yeah, design inertia.  Folk understand ioctls (more or less),
and not so much with sysfs.  Having to re-think anything is
a kind of obstacle.  (Part of why I made it especially easy
to add more attributes!)

Plus, if you dive into it ... you'll start noticing glitches
in the MTD framework models.  Object lifetime and all that;
arguably there should be new MTD calls and an altered object
lifecycle.  Such issues come up a lot with legacy interfaces,
and MTD counts as one.


> 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.

True.  Unless I need JFFS2 I don't enable mtd block devices;
and I don't use mtd-utils most of the time either...


> 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.
> 
> While there are up- and downwards compatibility issues, careful design of 
> the ioctls can minimize the impact.

As they say, "your mileage may vary" ... but ability to just
browse sysfs with "cat" and such is a big win.  No need to
operate any ioctls.

Erasing an MTD partition may require an ioctl forever.  :)


> I'm not suggesting we go one way or the other, just an observation that 
> few mtd _users_ seem to be eager to go with sysfs. I invite anyone to 
> prove me wrong...

Users just want to mount-and-go.
Sysadmins may use mtd-utils for repair/install.
Most system developers are just users with bloodier hardware.

MTD developers themselves probably have strong opinions and
needs, but that's not a large community... adaptable, though!

- Dave

 
> /Ricard
> --
> Ricard Wolf Wanderlöf                           ricardw(at)axis.com
> Axis Communications AB, Lund, Sweden            www.axis.com
> Phone +46 46 272 2016                           Fax +46 46 13 61 30
> 
> 

  parent reply	other threads:[~2009-04-01  8:05 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
2009-04-01  8:05     ` David Brownell [this message]
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=200904010105.33674.david-b@pacbell.net \
    --to=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