On Fri, 18 Jan 2008, Nick Piggin wrote: > > I thought in your last mail on the subject, that you had conceded the > vma-based scheme should stay, so I might have misunderstood that to mean > you would, reluctantly, go with the scheme. I guess I need to try a bit > harder ;) Yes, I did concede that apparently we cannot just mandate "let's just use a bit in the pte". So I do agree that we seem to be forced to have two different implementations: one for architectures where we can make use of a marker on the PTE itself (or perhaps some *other* way to distinguish things automatically), and one for the ones where we need to just be able to distinguish purely based on our own data structures. I just then didn't like the lack of abstraction. > How about taking a different approach. How about also having a pte_normal() > function. Well, one reason I'd prefer not to, is that I can well imagine an architecture that doesn't actually put the "normal" bit in the PTE itself, but in a separate data structure. In particular, let's say that you decide that - the architecture really doesn't have any space in the hw page tables - but for various reasons you *really* don't want to use the tricky "page->offset" logic etc - ..and you realize that PFNMAP and FIXMAP are actually very rare so.. - you just associate each PFNMAP/FIXMAP vma with a simple bitmap that contains the "special" bit. It's actually not that hard to do. If you have an architecture-specific interface like struct page *vm_normal_page(struct vm_area_struct *vma, unsigned long addr, pte_t pte); then it wouldn't be too hard at all to create a hash lookup on the VMA (or perhaps on a "vma, 256-page-aligned(addr)" tuple) to look up a bitmap, and then use the address to see if it was marked special or not. But yes, then you'd also need to have that extended set_special_pte_at(vma, addr, pfn, prot); interface to set that bit in that bitmap. See? Is it better than what we already have for the generic case? Possibly not. But I like abstractions that aren't tied to *one* particular implementation. Linus - To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
