public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: ebiederman@lnxi.com (Eric W. Biederman)
To: "Jörn Engel" <joern@wohnheim.fh-wedel.de>
Cc: dwmw2@infradead.org, linux-mtd@lists.infradead.org,
	linux-kernel@vger.kernel.org, Arnd Bergmann <arnd@arndb.de>,
	Christoph Hellwig <hch@lst.de>
Subject: Re: [PATCH 06/25] mtd: move ioctl32 code to mtdchar.c
Date: Wed, 09 Nov 2005 08:37:16 -0700	[thread overview]
Message-ID: <m3slu5al3n.fsf@maxwell.lnxi.com> (raw)
In-Reply-To: <20051108183339.GB31446@wohnheim.fh-wedel.de> ( Jörn Engel's message of "Tue, 8 Nov 2005 19:33:39 +0100")

Jörn Engel <joern@wohnheim.fh-wedel.de> writes:

> mtdchar.c is one of the worst drivers inside the kernel.  The concept
> of having a simple char device driver for flash may have its charm,
> but the actual implementation is horrible.  And things like the
> read-only devices are even unfixable.

This is a confusing statement, you complain that the implementation is horrible
and then go on to complain about the interface to the character device.

The implementation appears small and concise.   There are a couple of
FIXMEs but they are all about wishing the interface to the flash chips
mapped better to a user space interface.  I routinely fix things in
the kernel whose implementations are much worse than mtdchar. 

> Can you name a few examples, where mtdchar.c makes sense?  I've found
> it to be quite useless.

I have found just the opposite.  It happens to be the only interface
to mtd devices I use.   In general when you have flash devices small
enough that you can't use a filesystem without waisting a lot of space
(keeping 1 free erase block out of 4 or 8 is a problem).  Or when you are
doing low-level mucking mtdchar is invaluable.

As for the interface to mtdchar.  I agree that the readonly character
device is silly, and does weird things to the mtd device minor numbers.
I agree that ioctls are not the prettiest interface around, however
the raw functionality the ioctls export is needed, and interesting.  Some
of the functionality would be hard to export even in sysfs the cool ascii
replacement for ioctl.

Long term it does look like a sysfs interface to the mtd functionality
could suffice.

Eric

  parent reply	other threads:[~2005-11-09 15:37 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-11-05 16:26 [PATCH 00/25] reduce code in fs/compat_ioctl.c Arnd Bergmann
2005-11-05 16:26 ` [PATCH 06/25] mtd: move ioctl32 code to mtdchar.c Arnd Bergmann
2005-11-08 10:59   ` Jörn Engel
2005-11-08 18:10     ` Eric W. Biederman
2005-11-08 18:33       ` Jörn Engel
2005-11-08 18:45         ` Josh Boyer
2005-11-08 18:57         ` Thomas Gleixner
2005-11-08 22:21           ` Jörn Engel
2005-11-09  0:04             ` Thomas Gleixner
2005-11-08 19:03         ` David Woodhouse
2005-11-09 15:37         ` Eric W. Biederman [this message]
2005-11-09 15:48           ` Jörn Engel

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=m3slu5al3n.fsf@maxwell.lnxi.com \
    --to=ebiederman@lnxi.com \
    --cc=arnd@arndb.de \
    --cc=dwmw2@infradead.org \
    --cc=hch@lst.de \
    --cc=joern@wohnheim.fh-wedel.de \
    --cc=linux-kernel@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