On Wed, 17 May 2006, Andi Kleen wrote: > On Wednesday 17 May 2006 12:46, Steven Rostedt wrote: > > > > On Wed, 17 May 2006, Andi Kleen wrote: > > > > > > > > > As well as the following three functions: > > > > > > > > pud_t *pud_boot_alloc(struct mm_struct *mm, pgd_t *pgd, unsigned long addr, > > > > int cpu); > > > > pmd_t *pmd_boot_alloc(struct mm_struct *mm, pud_t *pud, unsigned long addr, > > > > int cpu); > > > > pte_t *pte_boot_alloc(struct mm_struct *mm, pmd_t *pmd, unsigned long addr, > > > > int cpu); > > > > > > I'm not sure you can just put them like this into generic code. Some > > > architectures are doing strange things with them. > > > > Hmm, like what? > > Mostly managing their software TLBs I think. Wait. "into generic code"? Do you mean that we can't use them in generic code. The are not defined there, but are defined in the arch. They are just used like the p*_alloc (without boot) equivalents (from vmalloc.c). > > > > > > > And we already have boot_ioremap on some architectures. Why is that not > > > enough? > > > > I thought about using boot_ioremap, but it seems to be an abuse. Since > > I'm not mapping io, but actual memory pages. > > We already use it for memory, e.g. for mapping some BIOS tables. > > > So the solution to that > > seemed more of a hack. I then would need to worry about grabbing pages > > that were node specific > > alloc_bootmem_node > > > and getting the physical addresses. > > virt_to_phys() > > [ + hacks to handle 32bit NUMA unfortunately ] With the archs defining their own p*_boot_alloc functions, there shouldn't be any hacks. The arch can figure out what to do. I didn't want any hacks in the generic code. -- Steve - : send the line "unsubscribe linux-ia64" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
|