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

[Xen-ia64-devel] RE: [Xen-devel] RE: Linux PG_arch_1 conflict



>From: Isaku Yamahata
>Sent: 2006年3月14日 10:12
>> > > Comments, Keir (or others)?
>> >
>> > Sounds like the proper fix. I'll leave it to Christian and others
>> > involved in the Linux upstreaming effort to have the final word.
>>
>> Comments, Christian (or others)?  Any chance this will get into
>> 3.0.2?  Certainly it should be changed before attempting to push
>> the drivers upstream to Linux.
>
>What do you think of the followings? Too hacky?
>
>
>extern struct address_space xen_ia64_foreign_dummy_mapping;
>#define PageForeign(page)      \
>       (page->mapping == &xen_ia64_foreign_dummy_mapping)
>
>#define SetPageForeign(page, dtor) do {                                \
>       set_page_private((page), (unsigned long)dtor);          \
>       (page)->mapping = &xen_ia64_foreign_dummy_mapping;      \
>} while (0)
>
>#define ClearPageForeign(page) do {    \
>       (page)->mapping = NULL;         \
>       set_page_private((page), 0);    \
>} while (0)
>
>#define PageForeignDestructor(page)    \
>       ( (void (*) (struct page *)) page_private((page)) )
>

Hi, Isaku,
        (page)->mapping is used to keep special destructor since that foreign 
page needs to be freed differently as normal linux pages, as you see in 
foreign_page.h. Your hack only ensures the check. Agree right way to go to 
propose PG_foreign upstream.

Thanks,
Kevin

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


 


Rackspace

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