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

>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@lists.xensource.com
http://lists.xensource.com/xen-devel