From: Jens Axboe <axboe@suse.de>
To: "David S. Miller" <davem@redhat.com>
Cc: linux-kernel@vger.kernel.org, andrea@suse.de
Subject: Re: [patch] zero-bounce highmem I/O
Date: Wed, 15 Aug 2001 15:10:52 +0200 [thread overview]
Message-ID: <20010815151052.C4352@suse.de> (raw)
In-Reply-To: <20010815131335.H545@suse.de> <20010815.044757.112624116.davem@redhat.com> <20010815140740.A4352@suse.de> <20010815.053524.48804759.davem@redhat.com>
In-Reply-To: <20010815.053524.48804759.davem@redhat.com>
On Wed, Aug 15 2001, David S. Miller wrote:
> 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
Yes, the pci_* was not my worry. It's the *address case you list below,
but I think you are right that it' not a big issue at that.
> 2.4.x is the "if (address != NULL) virt_to_bus(address);" stuff.
Yes, aka the horrible hack.
> 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).
I've read these now, been behind on traffic lately.
> 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.
The SCSI issue was exactly what was on my mind, and is indeed the reason
why I didn't go all the way and did a complete conversion there. The
SCSI layer is _not_ very clean in this regard, didn't exactly enjoy this
part of the work...
> 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, I see where you are going :)
> 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?
Fine
--
Jens Axboe
next prev parent reply other threads:[~2001-08-15 13:09 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-08-15 7:50 [patch] zero-bounce highmem I/O Jens Axboe
2001-08-15 9:11 ` David S. Miller
2001-08-15 9:17 ` Jens Axboe
2001-08-15 9:26 ` Jens Axboe
2001-08-15 10:22 ` David S. Miller
2001-08-15 11:13 ` Jens Axboe
2001-08-15 11:47 ` David S. Miller
2001-08-15 12:07 ` Jens Axboe
2001-08-15 12:35 ` David S. Miller
2001-08-15 13:10 ` Jens Axboe [this message]
2001-08-15 14:25 ` David S. Miller
2001-08-16 11:51 ` Jens Axboe
2001-08-16 11:56 ` David S. Miller
2001-08-16 12:03 ` Jens Axboe
2001-08-16 12:14 ` Gerd Knorr
2001-08-16 12:27 ` David S. Miller
2001-08-16 12:48 ` Jens Axboe
2001-08-16 12:56 ` Jens Axboe
2001-08-16 13:08 ` David S. Miller
2001-08-16 12:34 ` David S. Miller
2001-08-16 13:35 ` Gerd Knorr
2001-08-16 14:15 ` David S. Miller
2001-08-16 12:28 ` kill alt_address (Re: [patch] zero-bounce highmem I/O) David S. Miller
2001-08-15 14:02 ` [patch] zero-bounce highmem I/O David S. Miller
2001-08-16 5:52 ` Jens Axboe
2001-08-15 19:20 ` Gérard Roudier
2001-08-16 8:12 ` David S. Miller
[not found] <no.id>
2001-08-16 14:56 ` Alan Cox
2001-08-17 10:18 ` Gerd Knorr
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=20010815151052.C4352@suse.de \
--to=axboe@suse.de \
--cc=andrea@suse.de \
--cc=davem@redhat.com \
--cc=linux-kernel@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).