[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.