linux-kernel - Re: [PATCH 18/18] block: implement and enforce request peek/start/fetch

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 for Android: free password hash cracker in your pocket

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

Message-Id: <200905102352.33478.bzolnier@gmail.com>
Date:	Sun, 10 May 2009 23:52:32 +0200
From:	Bartlomiej Zolnierkiewicz <bzolnier@...il.com>
To:	Tejun Heo <tj@...nel.org>
Cc:	linux-kernel@...r.kernel.org, linux-scsi@...r.kernel.org,
	linux-ide@...r.kernel.org, rusty@...tcorp.com.au,
	James.Bottomley@...senpartnership.com, mike.miller@...com,
	donari75@...il.com, paul.clements@...eleye.com, tim@...erelk.net,
	Geert.Uytterhoeven@...ycom.com, davem@...emloft.net,
	Laurent@...vier.info, jgarzik@...ox.com, jeremy@...source.com,
	grant.likely@...retlab.ca, adrian@...en.demon.co.uk,
	sfr@...b.auug.org.au, petkovbb@...glemail.com,
	sshtylyov@...mvista.com, oakad@...oo.com, drzeus@...eus.cx,
	dwmw2@...radead.org, Markus.Lidel@...dowconnect.com,
	wein@...ibm.com, schwidefsky@...ibm.com, zaitcev@...hat.com,
	fujita.tomonori@....ntt.co.jp, axboe@...nel.dk
Subject: Re: [PATCH 18/18] block: implement and enforce request peek/start/fetch

On Friday 08 May 2009 04:54:16 Tejun Heo wrote:
> Till now block layer allowed two separate modes of request execution.
> A request is always acquired from the request queue via
> elv_next_request().  After that, drivers are free to either dequeue it
> or process it without dequeueing.  Dequeue allows elv_next_request()
> to return the next request so that multiple requests can be in flight.
> 
> Executing requests without dequeueing has its merits mostly in
> allowing drivers for simpler devices which can't do sg to deal with
> segments only without considering request boundary.  However, the
> benefit this brings is dubious and declining while the cost of the API
> ambiguity is increasing.  Segment based drivers are usually for very
> old or limited devices and as converting to dequeueing model isn't
> difficult, it doesn't justify the API overhead it puts on block layer
> and its more modern users.
> 
> Previous patches converted all block low level drivers to dequeueing
> model.  This patch completes the API transition by...
> 
> * renaming elv_next_request() to blk_peek_request()
> 
> * renaming blkdev_dequeue_request() to blk_start_request()
> 
> * adding blk_fetch_request() which is combination of peek and start
> 
> * disallowing completion of queued (not started) requests
> 
> * applying new API to all LLDs
> 
> Renamings are for consistency and to break out of tree code so that
> it's apparent that out of tree drivers need updating.
> 
> [ Impact: block request issue API cleanup, no functional change ]
> 
> Signed-off-by: Tejun Heo <tj@...nel.org>

Acked-by: Bartlomiej Zolnierkiewicz <bzolnier@...il.com>
--
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/