linux-kernel - Re: [PATCH 1/4] scatterlist: new helper functions

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 16 Mar 2011 20:46:18 -0700 (PDT)
From:	Alex Dubov <oakad@...oo.com>
To:	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>
Cc:	akpm@...ux-foundation.org, fujita.tomonori@....ntt.co.jp,
	maximlevitsky@...il.com, James.Bottomley@...senPartnership.com,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/4] scatterlist: new helper functions

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/