All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alex Dubov <oakad@yahoo.com>
To: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: akpm@linux-foundation.org, fujita.tomonori@lab.ntt.co.jp,
	maximlevitsky@gmail.com, James.Bottomley@HansenPartnership.com,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/4] scatterlist: new helper functions
Date: Wed, 16 Mar 2011 20:46:18 -0700 (PDT)	[thread overview]
Message-ID: <722844.29100.qm@web37604.mail.mud.yahoo.com> (raw)
In-Reply-To: <20110316135528U.fujita.tomonori@lab.ntt.co.jp>

> 
> Why?
> 
> Why can't the block layer split a request in the way the
> driver wants
> to do?
> 
> That is, why can't the driver tell the block layer how to
> split a
> request?

What is needed is the ability to get fixed sized (in bytes) blocks from 
the block layer.

Last time I checked (it was a long time ago, admittedly) one could only
ask for a fixed number of sg entries, without any control on how many
bytes each sg entry references.

Is there a way to get data from the block layer in a fashion of:
"Give me 16k/32k/whatever in one sg entry if request is equal or larger
than this"?

If my knowledge is correct, MTD currently addresses this issue by
maintaining its own cache, which it uses to aggregate write requests until
it can write a whole erase block. While this is ok with old media
(legacy memory stick being an example of such), new flash chips can
have multi-megabyte sized erase blocks and can benefit from operations
(like copy and compare) directly on scatter list .



      

  reply	other threads:[~2011-03-17  3:46 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-04  4:16 [PATH 0/4] Memstick patches for 2.6.39 Maxim Levitsky
2011-03-04  4:16 ` [PATCH 1/4] scatterlist: new helper functions Maxim Levitsky
2011-03-06  7:29   ` FUJITA Tomonori
2011-03-06 15:14     ` Maxim Levitsky
2011-03-06 21:49       ` FUJITA Tomonori
2011-03-07  2:20         ` Maxim Levitsky
2011-03-09 17:24           ` Maxim Levitsky
2011-03-16  0:44           ` Andrew Morton
2011-03-16  2:35             ` FUJITA Tomonori
2011-03-16  4:18               ` Alex Dubov
2011-03-16  4:55                 ` FUJITA Tomonori
2011-03-17  3:46                   ` Alex Dubov [this message]
2011-03-17  3:57                     ` James Bottomley
2011-03-16 22:33                 ` Andrew Morton
2011-03-17  6:41                   ` Alex Dubov
2011-03-17 13:17                     ` Maxim Levitsky
2011-03-18  0:59                     ` FUJITA Tomonori
2011-03-04  4:16 ` [PATCH 2/4] memstick: add support for legacy memorysticks Maxim Levitsky
2011-03-04  4:16 ` [PATCH 3/4] memstick: Add driver for Ricoh R5C592 card reader Maxim Levitsky
2011-03-16  4:25   ` Alex Dubov
2011-03-04  4:16 ` [PATCH 4/4] memstick: add Alex Dubov to MAINTAINERS of the memstick core Maxim Levitsky
2011-03-12 16:23 ` [PATH 0/4] Memstick patches for 2.6.39 Maxim Levitsky
2011-03-15 20:00   ` Maxim Levitsky
2011-03-15 21:04     ` Andrew Morton
2011-03-16  0:25       ` Maxim Levitsky
2011-03-20  3:09       ` Maxim Levitsky
2011-03-20  6:47         ` Andrew Morton
2011-03-20 11:42           ` Maxim Levitsky
2011-03-22 13:01             ` Maxim Levitsky
2011-03-22 23:21             ` Andrew Morton
2011-03-23  0:59               ` Maxim Levitsky
2011-03-23  3:42                 ` Greg KH
2011-03-23 15:30                   ` Maxim Levitsky
2011-03-24  3:27                     ` Alex Dubov
  -- strict thread matches above, loose matches on Subject: below --
2011-01-11 23:36 [PATCH V2 0/4]: MEMSTICK: My 2 drivers for 2.6.38 inclusion Maxim Levitsky
2011-01-11 23:36 ` [PATCH 1/4] scatterlist: new helper functions Maxim Levitsky
2011-01-11 23:51   ` Randy Dunlap
2011-01-11 23:55     ` Andrew Morton
2011-01-11 23:58       ` Randy Dunlap
2011-01-12  2:52         ` Maxim Levitsky
2011-01-12  6:41           ` Randy Dunlap
2011-01-11  2:58 Alex Dubov
2011-01-11  1:50 MEMSTICK: My 2 drivers for 2.6.38 inclusion Maxim Levitsky
2011-01-11  1:50 ` [PATCH 1/4] scatterlist: new helper functions Maxim Levitsky

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=722844.29100.qm@web37604.mail.mud.yahoo.com \
    --to=oakad@yahoo.com \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=akpm@linux-foundation.org \
    --cc=fujita.tomonori@lab.ntt.co.jp \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maximlevitsky@gmail.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 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.