WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

RE: [Xen-devel] PG_arch_1

To: "Magenheimer, Dan \(HP Labs Fort Collins\)" <dan.magenheimer@xxxxxx>, "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>
Subject: RE: [Xen-devel] PG_arch_1
From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Date: Fri, 9 Dec 2005 11:29:28 +0800
Cc: Xen Mailing List <xen-devel@xxxxxxxxxxxxxxxxxxx>, "Luck, Tony" <tony.luck@xxxxxxxxx>
Delivery-date: Fri, 09 Dec 2005 03:30:27 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcX76aHL/tOFq7o+TAq8iY3b//iXeAAGXHdgABmFyEAAAVVCkAAALjhA
Thread-topic: [Xen-devel] PG_arch_1
>From: Magenheimer, Dan (HP Labs Fort Collins) [mailto:dan.magenheimer@xxxxxx]
>Sent: 2005年12月9日 11:17
>> >In any case, PG_arch_1 is used for other purposes on ia64, ppc,
>> >ppc64, sparc64, arm, mips, pa-risc, and even has semantics for
>> >linux arch-neutral code (look for PG_Arch_1 in
>> >linux/Documentation/cachetlb.txt... does Xen depend on this
>> >behavior?), and the eventual goal is to merge upstream,
>> >it might be best if Xen defines it as a new bit ("PG_foreign"?
>> >no sense being vague by calling it PG_arch_2) rather than
>> >overloads PG_arch_1?
>>
>> I prefer to the "vague" name here. By using PG_foreign, how
>> can this bit be utilized by other places when running out of
>> virtualization world? Since these bits are *jealously*
>> guarded, name of the new bit should encourage more usages
>> instead of special purpose.
>
>That's exactly the problem.  If any Linux arch sees the bit
>as generic and decides to use it for some other purpose, then
>Xenlinux can't use it anymore.
>
>Dan

Ah, you're right. So how to balance? If suggesting to add a new flag which can 
only be exclusively used by one case, that's likely to see resistance. However 
if introducing a generic flag, same issue upon PG_arch_1 will happen as you 
said. ;-(

Thanks,
Kevin

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>