On Thu, 11 Nov 1999 14:00:31 +0100 (CET), Ingo Molnar
<mingo@chiara.csoma.elte.hu> said:
> On Thu, 11 Nov 1999, Stephen C. Tweedie wrote:
>> The _whole_ point about kiobufs is that they contain pages of
>> kernel-addressable memory, without _any_ information about where those
>> pages came from.
> i believe this is not generic enough. Eg. my box was already doing DMA to
> pages which were never-ever mapped into kernel-space. We do not need to
> _access_ page contents to do DMA to it, this is where the 'virtual
> address' assumption breaks.
I didn't say they were virtual addresses. :)
I explicitly said that the page addresses in the kiobuf are of the form
__va(physical address). That is deliberate: it means that a driver can
to virt_to_bus() or virt_to_phys() on the address and get something
which makes sense. I've already got people using kiobufs to do
zero-copy disk transfer of video framebuffer contents, for example.
I'm still open to persuasion on this, though --- I'd be happy in
principle to change the definition to store true physical addresses in
the kiobuf address vector. If we are to change that, though, it needs
to be done soon, before too many people start relying on things the way
they are right now.
The main argument for keeping it as a __va() address is that that has
always been the standard for IO addressing in things like bh->b_data.
I'm not wedded to the definition, but I do want the kiobuf address
argument to continue to be able to deal with unmapped physical
PCI-aperture pages cleanly. (Drivers can clearly identify such pages in
a kiobuf, btw, by spotting that the struct page * for the page is zero.)
The next kiobuf patch to Linus will include a Documentation/ file
explaining a lot of these details, btw.
--Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/