xen-devel
RE: [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> |
- [Xen-devel] PG_arch_1, Magenheimer, Dan (HP Labs Fort Collins)
- RE: [Xen-devel] PG_arch_1, Tian, Kevin
- RE: [Xen-devel] PG_arch_1, Magenheimer, Dan (HP Labs Fort Collins)
- RE: [Xen-devel] PG_arch_1, Tian, Kevin
- RE: [Xen-devel] PG_arch_1, Magenheimer, Dan (HP Labs Fort Collins)
- RE: [Xen-devel] PG_arch_1,
Tian, Kevin <=
|
|
|