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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
