[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <4948CAC3.76E4.0078.0@novell.com>
Date: Wed, 17 Dec 2008 08:47:47 +0000
From: "Jan Beulich" <jbeulich@...ell.com>
To: "FUJITA Tomonori" <fujita.tomonori@....ntt.co.jp>
Cc: <joerg.roedel@....com>, <ian.campbell@...rix.com>, <mingo@...e.hu>,
<jeremy@...p.org>, <x86@...nel.org>,
<xen-devel@...ts.xensource.com>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 00 of 14] swiotlb/x86: lay groundwork for xen dom0
useof swiotlb
>I think that the whole patchset is against the swiotlb design. swiotlb
>is designed to be used as a library. Each architecture implements the
>own swiotlb by using swiotlb library
>(e.g. arch/x86/kernel/pci-swiotlb_64.c).
If it is a library, then it should be prepared to serve all possible users.
>For example, adding the following code (9/14) for just Xen that the
>majority of swiotbl users (x86_64 and IA64) don't need to the library
>is against the design.
"Don't" in terms of "currently don't": Once x86-64 wants to support more
than 46 physical address bits, it's not impossible that this would lead to
CONFIG_HIGHMEM getting introduced there, and then it'll be helpful that the
code is already prepared to deal with that case.
After all, the code portion in question ought to compile to nothing if
!CONFIG_HIGHMEM.
Jan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists