[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200903142023.14747.bzolnier@gmail.com>
Date: Sat, 14 Mar 2009 20:23:14 +0100
From: Bartlomiej Zolnierkiewicz <bzolnier@...il.com>
To: Tejun Heo <tj@...nel.org>
Cc: axboe@...nel.dk, linux-kernel@...r.kernel.org,
Russell King <rmk@....linux.org.uk>,
Stephen Rothwell <sfr@...b.auug.org.au>,
Mike Miller <mike.miller@...com>,
Martin Schwidefsky <schwidefsky@...ibm.com>,
Jeff Garzik <jgarzik@...ox.com>,
Rusty Russell <rusty@...tcorp.com.au>,
Jeremy Fitzhardinge <jeremy@...source.com>,
Alex Dubov <oakad@...oo.com>,
James Bottomley <James.Bottomley@...senpartnership.com>
Subject: Re: [PATCH 11/14] block: implement and use [__]blk_end_request_all()
On Saturday 14 March 2009, Tejun Heo wrote:
> Hello, Bartlomiej. :-)
Hi!
> Bartlomiej Zolnierkiewicz wrote:
[...]
> >> diff --git a/drivers/ide/ide-pm.c b/drivers/ide/ide-pm.c
> >> index 60538d9..d3d2d29 100644
> >> --- a/drivers/ide/ide-pm.c
> >> +++ b/drivers/ide/ide-pm.c
> >> @@ -194,8 +194,7 @@ void ide_complete_pm_request(ide_drive_t *drive, struct request *rq)
> >>
> >> drive->hwif->rq = NULL;
> >>
> >> - if (blk_end_request(rq, 0, 0))
> >> - BUG();
> >> + blk_end_request_all(rq, 0);
> >
> > 0 => ide_rq_bytes() _not_ blk_rq_bytes()
>
> Can you elaborate a bit? Isn't the request supposed to always
> completely finish here? If the request isn't zero-length, completion
> with 0 byte length doesn't make any sense.
Arghh, just ignore me on this one -- my brain must have already started
switching into the power saving...
[ This is blk_end_request() not ide_end_request() call so "0 == 0". ]
> > Please convert ide_complete_pm_request() to use blk_rq_bytes() in
> > the separate pre-patch first.
>
> Alright, will do.
No need to, please just put the comment about 0 => blk_rq_bytes()
conversion so people will know that this is an intended change when
reviewing the patch.
> > More generic comment follows -> this patch is guaranteed to clash
> > with at least linux-next/pata-2.6 tree so why not introduce block
> > layer helpers now, then push all driver updates through respective
> > driver maintainers and deal with end_request() later (after all
> > driver updates are in-tree)?
>
> Most of the lld changes being trivial, I was hoping to push things
> through blk tree, but IDE seems to be the most intertwined with the
> block layer and it's likely to see quite some amount of not-so-trivial
> changes to subtle paths. How about pushing !IDE parts into blk tree
> and pulling blk into pata-2.6, make IDE related changes there and
> pulling back into blk tree so that further progresses can be made?
There is a "tiny" problem with this -- pata-2.6 is a quilt tree based on
Linus' tree and it is not going to change for now (for various reasons).
Thanks,
Bart
--
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/
Powered by blists - more mailing lists