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

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

>From: Isaku Yamahata
>Sent: 2006年3月14日 12:43
>> >
>> >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.
>
>A special destructor is kept in page->private by set_page_private() and
>get by page_private(). page->private is unsigned long so that it can
>hold pointer value.
>
>They are just defined as
>#define page_private(page)              ((page)->private)
>#define set_page_private(page, v)       ((page)->private = (v))

Oops, I didn't note that. :-)

Thanks,
Kevin

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