From: "David S. Miller" <davem@redhat.com>
To: torvalds@transmeta.com
Cc: andrea@suse.de, eyal@eyal.emu.id.au, linux-kernel@vger.kernel.org
Subject: Re: 2.4.8aa1
Date: Sun, 12 Aug 2001 20:29:18 -0700 (PDT) [thread overview]
Message-ID: <20010812.202918.48532196.davem@redhat.com> (raw)
In-Reply-To: <Pine.LNX.4.33.0108121003520.15697-100000@penguin.transmeta.com>
In-Reply-To: <20010812190202.H737@athlon.random> <Pine.LNX.4.33.0108121003520.15697-100000@penguin.transmeta.com>
From: Linus Torvalds <torvalds@transmeta.com>
Date: Sun, 12 Aug 2001 10:21:58 -0700 (PDT)
On Sun, 12 Aug 2001, Andrea Arcangeli wrote:
> So I believe a kind of page_to_bus64 should be implemented, and it should
> possibly return dma64_addr_t typedeffed as 'unsigned long long'.
Fair enough, that sounds like a good idea too.
I agree with the dma64_addr_t type, but I don't know if I agree
with the logistics of how drivers go about doing things and what
the interfaces are that an architecture implements.
First, maybe I'm confused about intent. Are we trying to just hack
together something quick for 2.4.x that allows PCI drivers on highmem
machines to get at the complete low 4GB of physical memory, even the
highmem parts?
If this is the case, then I have no strong opinions about what you do
because I know I will be able to retrofit my ports into whatever
interfaces you come up with for that (f.e. the pci_kmap()/pci_kunmap()
stuff).
But if this is more far reaching, ie. a 64-bit addressing API for
drivers, my thinking is that this is a larger problem to solve.
For example, if you're talking seriously about sending page/off/len
triplets to the drivers (which is what we want in the end), then with
that I can whip together something really nice and portable in about
a weekend of thinking and hacking.
The only reason I haven't done this work yet is strictly because the
drivers aren't getting pages yet (well, the zerocopy aware networking
drivers are). It was my understanding that this is the bit that Jens
Axboe and Andrea are working on.
Later,
David S. Miller
davem@redhat.com
next prev parent reply other threads:[~2001-08-13 3:29 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-08-11 12:58 2.4.8aa1 Andrea Arcangeli
2001-08-11 13:32 ` 2.4.8aa1 Eyal Lebedinsky
2001-08-11 14:02 ` 2.4.8aa1 Andrea Arcangeli
2001-08-11 18:20 ` 2.4.8aa1 Linus Torvalds
2001-08-12 17:02 ` 2.4.8aa1 Andrea Arcangeli
2001-08-12 17:21 ` 2.4.8aa1 Linus Torvalds
2001-08-12 18:49 ` 2.4.8aa1 Andrea Arcangeli
2001-08-13 3:29 ` David S. Miller [this message]
2001-08-13 5:44 ` 2.4.8aa1 Linus Torvalds
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=20010812.202918.48532196.davem@redhat.com \
--to=davem@redhat.com \
--cc=andrea@suse.de \
--cc=eyal@eyal.emu.id.au \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@transmeta.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.