On Wed, Jun 07, 2006 at 11:00:05PM +0900, Magnus Damm wrote: > Maybe I'm misunderstanding, but a "statically allocated page table" > sounds like a set of pages that are compiled in the kernel. With my > patch the page tables are allocated during "prepare", ie when the new > kernel is loaded with the kexec tool. Until that time no extra pages > are used by the kernel. This is quite different from a "statically > allocated page table" which is using the pages regardless of if a new > kernel is loaded or not. > > >>Also, how can you > >> be sure that the static pages are in a DMA-safe address range? > >> > > > >Why would kernel setup DMA on statically allocated pages? > > You tell me. =) My patch is using kimage_alloc_control_pages() and my > code assumes that it gets DMA-safe pages from that function. If you > think my code is unsafe please let me know. > > Maybe it's no problem but I cannot see any advantage of static page > tables. I just think it is overly complex with no special reason. I'm > thinking about CONFIG_PHYSICAL_START and how to always make sure the > pages are in a good non-conflicting range. > kimage_alloc_control_pages() already handles the range issue for us, > and I'm not sure how to guarantee that for statically allocated pages. >
I think Eric is talking of only to allocate page_table_a statically. I think CONFIG_PHYSICAL_START should not be a problem. You anyway will switch to page_table_b before you start copying the pages and overwrite the previous kernel's text section. Kernel also should not set up DMA to these statically allocated pages so there is no problem in allocating page_table_a statically AFAIKS. I don't know what are the advantages of static allocation. Eric can throw some light. Thanks Vivek _______________________________________________ fastboot mailing list [email protected] https://lists.osdl.org/mailman/listinfo/fastboot
