13 May, 2008

1 commit

  • Reintroduce uml_kmalloc for the benefit of UML libc code. The
    previous tactic of declaring __kmalloc so it could be called directly
    from the libc side of the house turned out to be getting too intimate
    with slab, and it doesn't work with slob.

    So, the uml_kmalloc wrapper is back. It calls kmalloc or whatever
    that translates into, and libc code calls it.

    kfree is left alone since that still works, leaving a somewhat
    inconsistent API.

    Signed-off-by: Jeff Dike
    Cc: WANG Cong
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jeff Dike
     

17 Jul, 2007

1 commit

  • UML had two wrapper procedures for kmalloc, um_kmalloc and um_kmalloc_atomic
    because the flag constants weren't available in userspace code.
    kern_constants.h had made kernel constants available for a long time, so there
    is no need for these wrappers any more. Rather, userspace code calls kmalloc
    directly with the userspace versions of the gfp flags.

    kmalloc isn't a real procedure, so I had to essentially copy the inline
    wrapper around __kmalloc.

    vmalloc also had its own wrapper for no good reason. This is now gone.

    Signed-off-by: Jeff Dike
    Cc: Paolo 'Blaisorblade' Giarrusso
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jeff Dike
     

08 May, 2007

4 commits


21 Oct, 2006

1 commit


11 Apr, 2006

1 commit

  • Since on some 64-bit systems __u64 is rightfully defined to unsigned long and
    GCC recognizes anyway unsigned long and unsigned long long as different, fix
    some types back to being unsigned long long to avoid warnings and errors (for
    prototype mismatch) on those systems.

    Thanks to the report by Wesley Emeneker wesleyemeneker (at) google (dot) com

    Signed-off-by: Paolo 'Blaisorblade' Giarrusso
    Cc: Jeff Dike
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Paolo 'Blaisorblade' Giarrusso
     

25 Feb, 2006

2 commits


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