Messages in this thread | | | Date | Wed, 15 Aug 2001 05:35:24 -0700 (PDT) | Subject | Re: [patch] zero-bounce highmem I/O | From | "David S. Miller" <> |
| |
From: Jens Axboe <axboe@suse.de> Date: Wed, 15 Aug 2001 14:07:40 +0200
Ok so you just want to turn scatterlist into what I call sg_list in 2.5 time, fine with me too. Depends on whether we want to keep the pci_map_sg and struct scatterlist interface intact, or just break it and tell driver authors they must fix their stuff regardless of whether they want to support highmem. As I write this sentence, it's clear to me which way is the superior :-)
pci_map_sg is pci_map_sg, if the internal representation of scatterlist is changed such that address/alt_address no longer exist, it will work on pages only. Right? The compatibility mode in 2.4.x is the "if (address != NULL) virt_to_bus(address);" stuff.
Understand that the pci64_{map,unmap}_sg is created for a seperate purpose, independant of whether scatterlist has the backwards compatability stuff or not. (There have been threads here about this, I can describe it quickly for you in quiet if you want to know).
Two more things to consider:
1) There is nobody who cannot be search&replace converted from sg->address = ptr into sg->page = virt_to_page(ptr) sg->offset = ((unsigned long)ptr & ~PAGE_MASK);
The only truly problematic area is the alt_address thing. It is would be a nice thing to rip this eyesore out of the scsi layer anyways.
2) I want to put scatterlist in to replace skb_frag_struct in skbuff.h and then have a zerocopy network driver do something like:
header_dma = pci_map_single(pdev, skb->data, skb->len, PCI_DMA_TODEVICE); data_nents = pci_map_sg(pdev, skb_shinfo(skb)->frag_list, skb_shinfo(skb)->nr_frags, PCI_DMA_TODEVICE);
See? :-)
Yep. Want me to add in the x86 parts of your patch?
Please let me finish up my prototype with sparc64 building and working, then I'll send you what I have ok?
Later, David S. Miller davem@redhat.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |