10 Sep, 2005

1 commit

  • Adds a set of primitives to do reference counting for objects that are looked
    up without locks using RCU.

    Signed-off-by: Ravikiran Thirumalai
    Signed-off-by: Dipankar Sarma
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Dipankar Sarma
     

01 May, 2005

2 commits

  • The synchronize_kernel() primitive is used for quite a few different purposes:
    waiting for RCU readers, waiting for NMIs, waiting for interrupts, and so on.
    This makes RCU code harder to read, since synchronize_kernel() might or might
    not have matching rcu_read_lock()s. This patch creates a new
    synchronize_rcu() that is to be used for RCU readers and a new
    synchronize_sched() that is used for the rest. These two new primitives
    currently have the same implementation, but this is might well change with
    additional real-time support. Both new primitives are GPL-only, the old
    primitive is deprecated.

    Signed-off-by: Paul E. McKenney
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Paul E. McKenney
     
  • The gpl exports need to be put back. Moving them to GPL -- but in a
    measured manner, as I proposed on this list some months ago -- is fine.
    Changing these particular exports precipitously is most definitely -not-
    fine. Here is my earlier proposal:

    http://marc.theaimsgroup.com/?l=linux-kernel&m=110520930301813&w=2

    See below for a patch that puts the exports back, along with an updated
    version of my earlier patch that starts the process of moving them to GPL.
    I will also be following this message with RFC patches that introduce two
    (EXPORT_SYMBOL_GPL) interfaces to replace synchronize_kernel(), which then
    becomes deprecated.

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

    Paul E. McKenney
     

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