26 Sep, 2006

1 commit

  • One of the changes necessary for shared page tables is to standardize the
    pxx_page macros. pte_page and pmd_page have always returned the struct
    page associated with their entry, while pte_page_kernel and pmd_page_kernel
    have returned the kernel virtual address. pud_page and pgd_page, on the
    other hand, return the kernel virtual address.

    Shared page tables needs pud_page and pgd_page to return the actual page
    structures. There are very few actual users of these functions, so it is
    simple to standardize their usage.

    Since this is basic cleanup, I am submitting these changes as a standalone
    patch. Per Hugh Dickins' comments about it, I am also changing the
    pxx_page_kernel macros to pxx_page_vaddr to clarify their meaning.

    Signed-off-by: Dave McCracken
    Cc: Hugh Dickins
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Dave McCracken
     

30 Oct, 2005

1 commit

  • It seems odd to me that, whereas pud_alloc and pmd_alloc test inline, only
    calling out-of-line __pud_alloc __pmd_alloc if allocation needed,
    pte_alloc_map and pte_alloc_kernel are entirely out-of-line. Though it does
    add a little to kernel size, change them to macros testing inline, calling
    __pte_alloc or __pte_alloc_kernel to allocate out-of-line. Mark none of them
    as fastcalls, leave that to CONFIG_REGPARM or not.

    It also seems more natural for the out-of-line functions to leave the offset
    calculation and map to the inline, which has to do it anyway for the common
    case. At least mremap move wants __pte_alloc without _map.

    Macros rather than inline functions, certainly to avoid the header file issues
    which arise from CONFIG_HIGHPTE needing kmap_types.h, but also in case any
    architectures I haven't built would have other such problems.

    Signed-off-by: Hugh Dickins
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Hugh Dickins
     

17 Apr, 2005

1 commit

  • Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds