From: David Brownell <david-b@pacbell.net>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Kyungmin Park <kmpark@infradead.org>,
linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org,
Michael Trimarchi <trimarchimichael@yahoo.it>,
spi-devel-general@lists.sourceforge.net,
Josh Boyer <jwboyer@gmail.com>,
dwmw2@infradead.org, linux-arm-kernel@lists.arm.linux.org.uk
Subject: Re: [PATCH] jffs2 summary allocation
Date: Fri, 4 Apr 2008 19:41:34 -0700 [thread overview]
Message-ID: <200804041941.35075.david-b@pacbell.net> (raw)
In-Reply-To: <20080404184615.deaf3122.akpm@linux-foundation.org>
On Friday 04 April 2008, Andrew Morton wrote:
> This problem comes up pretty often.
Which problem -- kmalloc(BIG)? Or dma(dma-unsafe-mem)?
Or something else?
The specific issue here might best be described as JFFS2
making a bad assumption: that MTD drivers never use DMA.
The I2C stack does that in some cases (for example, I/O
buffers in i2c_smbus_xfer_emulated are on-stack), but I'd
not call that an especially common assumption.
> Rather than open-coding it yet again
> it'd be nice to have a little bit of library code which manages an array of
> pages and which has accessors for common operations like
> read/write-u8/u16/u32/u64, memset, memcpy, etc.
If array-of-pages is to be more widely adopted, that'd
make sense. The MTD framework is a bit odd in that
respect ... it has block devices but doesn't use the
scatterlist primitives.
- Dave
WARNING: multiple messages have this Message-ID (diff)
From: David Brownell <david-b-yBeKhBN/0LDR7s880joybQ@public.gmane.org>
To: Andrew Morton <akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
Cc: Kyungmin Park <kmpark-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Michael Trimarchi <trimarchimichael-whZMOeQn8C0@public.gmane.org>,
spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org,
Josh Boyer <jwboyer-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org,
linux-arm-kernel-xIg/pKzrS19vn6HldHNs0ANdhmdF6hFW@public.gmane.org
Subject: Re: [PATCH] jffs2 summary allocation
Date: Fri, 4 Apr 2008 19:41:34 -0700 [thread overview]
Message-ID: <200804041941.35075.david-b@pacbell.net> (raw)
In-Reply-To: <20080404184615.deaf3122.akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
On Friday 04 April 2008, Andrew Morton wrote:
> This problem comes up pretty often.
Which problem -- kmalloc(BIG)? Or dma(dma-unsafe-mem)?
Or something else?
The specific issue here might best be described as JFFS2
making a bad assumption: that MTD drivers never use DMA.
The I2C stack does that in some cases (for example, I/O
buffers in i2c_smbus_xfer_emulated are on-stack), but I'd
not call that an especially common assumption.
> Rather than open-coding it yet again
> it'd be nice to have a little bit of library code which manages an array of
> pages and which has accessors for common operations like
> read/write-u8/u16/u32/u64, memset, memcpy, etc.
If array-of-pages is to be more widely adopted, that'd
make sense. The MTD framework is a bit odd in that
respect ... it has block devices but doesn't use the
scatterlist primitives.
- Dave
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Register now and save $200. Hurry, offer ends at 11:59 p.m.,
Monday, April 7! Use priority code J8TLD2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
WARNING: multiple messages have this Message-ID (diff)
From: David Brownell <david-b@pacbell.net>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: "Kyungmin Park" <kmpark@infradead.org>,
"Josh Boyer" <jwboyer@gmail.com>,
linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org,
"Michael Trimarchi" <trimarchimichael@yahoo.it>,
spi-devel-general@lists.sourceforge.net, dwmw2@infradead.org,
linux-arm-kernel@lists.arm.linux.org.uk
Subject: Re: [PATCH] jffs2 summary allocation
Date: Fri, 4 Apr 2008 19:41:34 -0700 [thread overview]
Message-ID: <200804041941.35075.david-b@pacbell.net> (raw)
In-Reply-To: <20080404184615.deaf3122.akpm@linux-foundation.org>
On Friday 04 April 2008, Andrew Morton wrote:
> This problem comes up pretty often.
Which problem -- kmalloc(BIG)? Or dma(dma-unsafe-mem)?
Or something else?
The specific issue here might best be described as JFFS2
making a bad assumption: that MTD drivers never use DMA.
The I2C stack does that in some cases (for example, I/O
buffers in i2c_smbus_xfer_emulated are on-stack), but I'd
not call that an especially common assumption.
> Rather than open-coding it yet again
> it'd be nice to have a little bit of library code which manages an array of
> pages and which has accessors for common operations like
> read/write-u8/u16/u32/u64, memset, memcpy, etc.
If array-of-pages is to be more widely adopted, that'd
make sense. The MTD framework is a bit odd in that
respect ... it has block devices but doesn't use the
scatterlist primitives.
- Dave
next prev parent reply other threads:[~2008-04-05 2:41 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-04 10:23 [PATCH] jffs2 summary allocation Michael Trimarchi
2008-04-04 10:23 ` Michael Trimarchi
2008-04-04 19:48 ` Andrew Morton
2008-04-04 19:48 ` Andrew Morton
2008-04-04 19:48 ` Andrew Morton
2008-04-04 20:09 ` Russell King - ARM Linux
2008-04-04 20:09 ` Russell King - ARM Linux
2008-04-04 20:09 ` Russell King - ARM Linux
2008-04-04 23:09 ` David Brownell
2008-04-04 23:09 ` David Brownell
2008-04-04 23:09 ` David Brownell
2008-04-04 23:21 ` Josh Boyer
2008-04-04 23:21 ` Josh Boyer
2008-04-04 23:21 ` Josh Boyer
2008-04-04 23:58 ` David Brownell
2008-04-04 23:58 ` David Brownell
2008-04-04 23:58 ` David Brownell
2008-04-05 1:11 ` Josh Boyer
2008-04-05 1:11 ` Josh Boyer
2008-04-05 1:11 ` Josh Boyer
2008-04-05 1:29 ` Kyungmin Park
2008-04-05 1:29 ` Kyungmin Park
2008-04-05 1:29 ` Kyungmin Park
2008-04-05 1:46 ` Andrew Morton
2008-04-05 1:46 ` Andrew Morton
2008-04-05 1:46 ` Andrew Morton
2008-04-05 2:41 ` David Brownell [this message]
2008-04-05 2:41 ` David Brownell
2008-04-05 2:41 ` David Brownell
2008-04-05 3:27 ` Andrew Morton
2008-04-05 3:27 ` Andrew Morton
2008-04-05 3:27 ` Andrew Morton
2008-04-05 2:17 ` David Brownell
2008-04-05 2:17 ` David Brownell
2008-04-05 2:17 ` David Brownell
-- strict thread matches above, loose matches on Subject: below --
2008-04-05 14:05 matthieu castet
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=200804041941.35075.david-b@pacbell.net \
--to=david-b@pacbell.net \
--cc=akpm@linux-foundation.org \
--cc=dwmw2@infradead.org \
--cc=jwboyer@gmail.com \
--cc=kmpark@infradead.org \
--cc=linux-arm-kernel@lists.arm.linux.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=spi-devel-general@lists.sourceforge.net \
--cc=trimarchimichael@yahoo.it \
/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.