|
[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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |