From: Tejun Heo <htejun@gmail.com>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Jeff Garzik <jeff@garzik.org>,
linux-scsi <linux-scsi@vger.kernel.org>,
linux-ide <linux-ide@vger.kernel.org>,
Jens Axboe <Jens.Axboe@oracle.com>,
FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Subject: Re: [PATCH RESEND number 2] libata: eliminate the home grown dma padding in favour of that provided by the block layer
Date: Tue, 05 Feb 2008 09:06:31 +0900 [thread overview]
Message-ID: <47A7A887.2040307@gmail.com> (raw)
In-Reply-To: <1202142222.3096.26.camel@localhost.localdomain>
James Bottomley wrote:
> Plus, tape devices are also ATAPI and since the problem seems to be
> handling of ATAPI pio commands, they need all of this too. It really
> is, I think, better just to do the setup in the libata slave configure
> if the device is atapi.
If no SCSI HBA needs it, fine.
> For all the rest, I think code demonstrates better ... well, except the
> sata_fsl.c update ... you leave in qc->n_iter, but it's only ever set to
> zero ... doesn't that cause this driver to break?
Probably. I was gonna cross check with your patch while splitting.
They seem mostly identical so I'll probably use your patch with some
modifications.
> I analysed all the places you use the expanded data length. To keep the
> true length in the request and add the drain if necessary, I think
> requires this update over my published libata drain patch. I've also
> added the request accessor to the drain buffer. Could you verify this
> actually works? If it does, it's better than all the additions to block
> and sr. It would probably help to resend the series rebased against git
> current.
No, it doesn't. Drain needs to extend the sg table too and it makes
controllers lax about buffer overruns for commands they shouldn't be.
Gee.. What's the deal with extra four bytes? If you're worried about
the size of struct request, chopping off PC request part into a separate
struct would be far better strategy than making what's already confusing
more confusing.
Thanks.
--
tejun
next prev parent reply other threads:[~2008-02-05 0:06 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-12-31 21:56 [PATCH] libata: eliminate the home grown dma padding in favour of that provided by the block layer James Bottomley
2007-12-31 22:56 ` Jeff Garzik
2008-01-03 7:58 ` FUJITA Tomonori
2008-01-03 15:12 ` James Bottomley
2008-01-09 2:10 ` Tejun Heo
2008-01-09 4:24 ` James Bottomley
2008-01-09 5:13 ` Tejun Heo
2008-01-09 15:13 ` James Bottomley
2008-01-18 23:14 ` [PATCH RESEND] " James Bottomley
2008-02-01 19:40 ` [PATCH RESEND number 2] " James Bottomley
2008-02-01 20:02 ` Jeff Garzik
2008-02-01 21:09 ` James Bottomley
2008-02-03 3:04 ` Tejun Heo
2008-02-03 4:32 ` James Bottomley
2008-02-03 7:37 ` Tejun Heo
2008-02-03 14:38 ` James Bottomley
2008-02-03 15:14 ` Tejun Heo
2008-02-03 16:12 ` James Bottomley
2008-02-03 16:38 ` Jeff Garzik
2008-02-03 17:12 ` James Bottomley
2008-02-04 1:21 ` Tejun Heo
2008-02-04 1:28 ` Tejun Heo
2008-02-04 9:25 ` Tejun Heo
2008-02-04 14:43 ` Tejun Heo
2008-02-04 16:23 ` James Bottomley
2008-02-05 0:06 ` Tejun Heo [this message]
2008-02-05 0:32 ` James Bottomley
2008-02-05 0:43 ` Tejun Heo
2008-02-05 0:53 ` James Bottomley
2008-02-05 1:07 ` Tejun Heo
2008-02-05 5:03 ` James Bottomley
2008-02-05 5:22 ` Tejun Heo
2008-02-04 15:43 ` James Bottomley
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=47A7A887.2040307@gmail.com \
--to=htejun@gmail.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=Jens.Axboe@oracle.com \
--cc=fujita.tomonori@lab.ntt.co.jp \
--cc=jeff@garzik.org \
--cc=linux-ide@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).