On Thu, 24 Aug 2000, Neil Brown wrote:
> >
> > Which implies that we should not have it in the generic path, but in the
> > per-queue path.
>
> I'm beginning to see your point...
>
> Maybe we should then have a "blk_queue_highmem_capable(q,flag)"
> function whereby drivers can tell elevator_make_request that they
> are highmem aware, and so the create_bounce will be skipped ??
No. No flags. That's the mistake SCSI did, and it is a fundamental
mistake. It makes it basically impossible to "shift out" old code.
I'd much rather have two separate functions for this - sure, they can
share most of the code by using common inline functions and what not, but
I'd be a lot happier with drivers just using the function that they are
most comfortable with directly.
Anyway, this is not a change I'd like to have at this point. This is
definitely a 2.5.x thing.
> md_make_request needs it (I thought) because it accesses the data in the
> buffers ... sometimes.
Yes. But like rd_make_request(), it only does so from the CPU, not from
any real device (obviously). So it doesn't actually need to create a
_physical_ bounce-buffer the way a real device needs to that does DMA etc.
It can just use the same "kmap()" functionality that all the other generic
kernel code uses.
Real devices are special. We don't know what they will end up doing, and
some (many) of them actually care deeply about the physical address as
opposed to just wanting to have the CPU able to touch the page.
> So, in summary:
> I was advocating the "keep it simple for now" position advocated by
> the comment, and applying the one solution to all drivers.
I agree with that notion. I don't think your patch was a bad one. I just
think that it would make it a more straightforward operation later when we
_do_ start to make it aware of clever devices to not do it the way you
did.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Aug 31 2000 - 21:00:13 EST