From: Stephane Chazelas <stephane.chazelas@emerson.com>
To: "Jörn Engel" <joern@logfs.org>
Cc: linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org,
Arnd Bergmann <arnd@arndb.de>
Subject: Re: [PATCH 2.6.24] block2mtd: removing a device and typo fixes
Date: Wed, 20 Feb 2008 17:02:31 +0000 [thread overview]
Message-ID: <chaz20080220170231.GV4539@artesyncp.com> (raw)
In-Reply-To: <20080220163042.GC5539@lazybastard.org>
2008-02-20 17:30:42 +0100, Jörn Engel:
> On Wed, 20 February 2008 14:43:39 +0000, Stephane Chazelas wrote:
> >
> > note that for "loop", you have /dev/loop0, /dev/loop1... which
> > makes it a pain to handle
> >
> > For block2mtd, you don't need several device files in /dev, you
> > only need one to pass ioctls down to create mtd devices.
> >
> > That may end up creating new /dev devices via mtdblock or
> > mtdblock_ro for instance.
> >
> > So I'm not sure reusing the "loop" ioctls is a good idea.
>
> /me notes that you dislike both existing interfaces and would prefer a
> third. How likely is it that you will still like the new interface two
> years down the road? How likely is it that everyone else will agree
> with you?
>
> In the end, a painful interface is still less painful than a choice of
> several incompatible ones. I used to think different and have burned my
> fingers often enough to learn the lesson. :)
[...]
Hi Jörn,
sorry, I wasn't very clear.
With "loop", you're doing an ioctl() to /dev/loop<x> so that
/dev/loop<x> become a block device associated with a given file.
Applying that strictly to block2mtd wouldn't make sense.
At the moment, when you create a new block2mtd, the only thing
you see is an entry in /proc/mtd.
You don't access that mtd device directly (there's no
/dev/mtd<x>). Instead, you may access it via a /dev/mtdblock<x>
if you have "block2mtd" for instance.
Here, what you need, is an API that gets a block device (with fd
or path) and an erase size and that returns a mtd identifier.
Best regards,
Stephane
WARNING: multiple messages have this Message-ID (diff)
From: Stephane Chazelas <stephane.chazelas@emerson.com>
To: "Jörn Engel" <joern@logfs.org>
Cc: Arnd Bergmann <arnd@arndb.de>,
linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org
Subject: Re: [PATCH 2.6.24] block2mtd: removing a device and typo fixes
Date: Wed, 20 Feb 2008 17:02:31 +0000 [thread overview]
Message-ID: <chaz20080220170231.GV4539@artesyncp.com> (raw)
In-Reply-To: <20080220163042.GC5539@lazybastard.org>
2008-02-20 17:30:42 +0100, Jörn Engel:
> On Wed, 20 February 2008 14:43:39 +0000, Stephane Chazelas wrote:
> >
> > note that for "loop", you have /dev/loop0, /dev/loop1... which
> > makes it a pain to handle
> >
> > For block2mtd, you don't need several device files in /dev, you
> > only need one to pass ioctls down to create mtd devices.
> >
> > That may end up creating new /dev devices via mtdblock or
> > mtdblock_ro for instance.
> >
> > So I'm not sure reusing the "loop" ioctls is a good idea.
>
> /me notes that you dislike both existing interfaces and would prefer a
> third. How likely is it that you will still like the new interface two
> years down the road? How likely is it that everyone else will agree
> with you?
>
> In the end, a painful interface is still less painful than a choice of
> several incompatible ones. I used to think different and have burned my
> fingers often enough to learn the lesson. :)
[...]
Hi Jörn,
sorry, I wasn't very clear.
With "loop", you're doing an ioctl() to /dev/loop<x> so that
/dev/loop<x> become a block device associated with a given file.
Applying that strictly to block2mtd wouldn't make sense.
At the moment, when you create a new block2mtd, the only thing
you see is an entry in /proc/mtd.
You don't access that mtd device directly (there's no
/dev/mtd<x>). Instead, you may access it via a /dev/mtdblock<x>
if you have "block2mtd" for instance.
Here, what you need, is an API that gets a block device (with fd
or path) and an erase size and that returns a mtd identifier.
Best regards,
Stephane
next prev parent reply other threads:[~2008-02-20 17:02 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-12 13:47 [PATCH 2.6.24] block2mtd: removing a device and typo fixes Stephane Chazelas
2008-02-12 13:47 ` Stephane Chazelas
2008-02-12 15:21 ` Jörn Engel
2008-02-12 15:21 ` Jörn Engel
2008-02-12 16:10 ` Stephane Chazelas
2008-02-12 16:10 ` Stephane Chazelas
2008-02-19 15:08 ` Jörn Engel
2008-02-19 15:08 ` Jörn Engel
2008-02-19 22:33 ` Arnd Bergmann
2008-02-19 22:33 ` Arnd Bergmann
2008-02-20 6:43 ` Jörn Engel
2008-02-20 6:43 ` Jörn Engel
2008-02-20 14:43 ` Stephane Chazelas
2008-02-20 14:43 ` Stephane Chazelas
2008-02-20 16:30 ` Jörn Engel
2008-02-20 16:30 ` Jörn Engel
2008-02-20 17:02 ` Stephane Chazelas [this message]
2008-02-20 17:02 ` Stephane Chazelas
2008-02-20 17:22 ` Jörn Engel
2008-02-20 17:22 ` Jörn Engel
2008-02-20 17:30 ` Stephane Chazelas
2008-02-20 17:30 ` Stephane Chazelas
2008-02-23 15:33 ` Jörn Engel
2008-02-23 15:33 ` Jörn Engel
2008-02-20 14:36 ` Stephane Chazelas
2008-02-20 14:36 ` Stephane Chazelas
2008-02-20 16:42 ` Jörn Engel
2008-02-20 16:42 ` Jörn Engel
2008-02-20 16:55 ` Stephane Chazelas
2008-02-20 16:55 ` Stephane Chazelas
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=chaz20080220170231.GV4539@artesyncp.com \
--to=stephane.chazelas@emerson.com \
--cc=arnd@arndb.de \
--cc=joern@logfs.org \
--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 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.