Re: [RFC 0/8] Move locking primitives into kernel/locking/
On Fri, Nov 08, 2013 at 08:37:48AM +0100, Peter Zijlstra wrote: > On Wed, Nov 06, 2013 at 06:29:21AM -0800, Paul E. McKenney wrote: > > On Tue, Nov 05, 2013 at 01:10:44PM +0100, Peter Zijlstra wrote: > > > Hi all, > > > > > > During Kernel Summit Dave mentioned that there wasn't a clear maintainer > > > for > > > locking bits. > > > > > > To remedy this Ingo suggested gathering all the various locking > > > primitives and > > > lockdep into a single place: kernel/locking/. > > > > > > I would further like to propose a MAINTAINERS entry like: > > > > > > LOCKING > > > M: Ingo Molnar > > > M: Peter Zijlstra > > > M:Oleg Nesterov > > > M:"Paul E. McKenney" > > > M:Linus Torvalds > > > T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git > > > locking/core > > > S: Maintained > > > F: kernel/locking/ > > > > > > Because for most 'fun' locking discussions we usually end up with at least > > > those people anyway :-) > > > > > > Comments? > > > > OK, I am in. > > > > How are we organizing this? I could imagine divvying up the various > > types of locks, having a minimum number of reviews or acks coupled > > with a maximum review time, or just requiring the full set of reviews > > and acks given the criticality of locking code. Other approaches? > > I would suggest something like an ack/review of at least 3/5, no hard > deadline, because as you say, its better to get locking right :-) Works for me! Thanx, Paul -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 0/8] Move locking primitives into kernel/locking/
On Fri, Nov 08, 2013 at 08:37:48AM +0100, Peter Zijlstra wrote: On Wed, Nov 06, 2013 at 06:29:21AM -0800, Paul E. McKenney wrote: On Tue, Nov 05, 2013 at 01:10:44PM +0100, Peter Zijlstra wrote: Hi all, During Kernel Summit Dave mentioned that there wasn't a clear maintainer for locking bits. To remedy this Ingo suggested gathering all the various locking primitives and lockdep into a single place: kernel/locking/. I would further like to propose a MAINTAINERS entry like: LOCKING M: Ingo Molnar mi...@redhat.com M: Peter Zijlstra pet...@infradead.org M:Oleg Nesterov o...@redhat.com M:Paul E. McKenney paul...@linux.vnet.ibm.com M:Linus Torvalds torva...@linux-foundation.org T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git locking/core S: Maintained F: kernel/locking/ Because for most 'fun' locking discussions we usually end up with at least those people anyway :-) Comments? OK, I am in. How are we organizing this? I could imagine divvying up the various types of locks, having a minimum number of reviews or acks coupled with a maximum review time, or just requiring the full set of reviews and acks given the criticality of locking code. Other approaches? I would suggest something like an ack/review of at least 3/5, no hard deadline, because as you say, its better to get locking right :-) Works for me! Thanx, Paul -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 0/8] Move locking primitives into kernel/locking/
On Wed, Nov 06, 2013 at 06:29:21AM -0800, Paul E. McKenney wrote: > On Tue, Nov 05, 2013 at 01:10:44PM +0100, Peter Zijlstra wrote: > > Hi all, > > > > During Kernel Summit Dave mentioned that there wasn't a clear maintainer for > > locking bits. > > > > To remedy this Ingo suggested gathering all the various locking primitives > > and > > lockdep into a single place: kernel/locking/. > > > > I would further like to propose a MAINTAINERS entry like: > > > > LOCKING > > M: Ingo Molnar > > M: Peter Zijlstra > > M: Oleg Nesterov > > M: "Paul E. McKenney" > > M: Linus Torvalds > > T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git > > locking/core > > S: Maintained > > F: kernel/locking/ > > > > Because for most 'fun' locking discussions we usually end up with at least > > those people anyway :-) > > > > Comments? > > OK, I am in. > > How are we organizing this? I could imagine divvying up the various > types of locks, having a minimum number of reviews or acks coupled > with a maximum review time, or just requiring the full set of reviews > and acks given the criticality of locking code. Other approaches? I would suggest something like an ack/review of at least 3/5, no hard deadline, because as you say, its better to get locking right :-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 0/8] Move locking primitives into kernel/locking/
On Wed, Nov 06, 2013 at 06:29:21AM -0800, Paul E. McKenney wrote: On Tue, Nov 05, 2013 at 01:10:44PM +0100, Peter Zijlstra wrote: Hi all, During Kernel Summit Dave mentioned that there wasn't a clear maintainer for locking bits. To remedy this Ingo suggested gathering all the various locking primitives and lockdep into a single place: kernel/locking/. I would further like to propose a MAINTAINERS entry like: LOCKING M: Ingo Molnar mi...@redhat.com M: Peter Zijlstra pet...@infradead.org M: Oleg Nesterov o...@redhat.com M: Paul E. McKenney paul...@linux.vnet.ibm.com M: Linus Torvalds torva...@linux-foundation.org T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git locking/core S: Maintained F: kernel/locking/ Because for most 'fun' locking discussions we usually end up with at least those people anyway :-) Comments? OK, I am in. How are we organizing this? I could imagine divvying up the various types of locks, having a minimum number of reviews or acks coupled with a maximum review time, or just requiring the full set of reviews and acks given the criticality of locking code. Other approaches? I would suggest something like an ack/review of at least 3/5, no hard deadline, because as you say, its better to get locking right :-) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 0/8] Move locking primitives into kernel/locking/
On Tue, Nov 05, 2013 at 01:10:44PM +0100, Peter Zijlstra wrote: > Hi all, > > During Kernel Summit Dave mentioned that there wasn't a clear maintainer for > locking bits. > > To remedy this Ingo suggested gathering all the various locking primitives and > lockdep into a single place: kernel/locking/. > > I would further like to propose a MAINTAINERS entry like: > > LOCKING > M: Ingo Molnar > M: Peter Zijlstra > M:Oleg Nesterov > M:"Paul E. McKenney" > M:Linus Torvalds > T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git > locking/core > S: Maintained > F: kernel/locking/ > > Because for most 'fun' locking discussions we usually end up with at least > those people anyway :-) > > Comments? OK, I am in. How are we organizing this? I could imagine divvying up the various types of locks, having a minimum number of reviews or acks coupled with a maximum review time, or just requiring the full set of reviews and acks given the criticality of locking code. Other approaches? Thanx, Paul > --- > kernel/lglock.c| 89 > kernel/lockdep.c | 4257 --- > kernel/lockdep_internals.h | 170 - > kernel/lockdep_proc.c | 683 - > kernel/lockdep_states.h|9 > kernel/mutex-debug.c | 110 > kernel/mutex-debug.h | 55 > kernel/mutex.c | 960 --- > kernel/mutex.h | 48 > kernel/rtmutex-debug.c | 187 - > kernel/rtmutex-debug.h | 33 > kernel/rtmutex-tester.c| 420 --- > kernel/rtmutex.c | 1060 > kernel/rtmutex.h | 26 > kernel/rtmutex_common.h| 126 - > kernel/rwsem.c | 157 - > kernel/semaphore.c | 263 -- > kernel/spinlock.c | 399 --- > lib/percpu-rwsem.c | 165 - > lib/rwsem-spinlock.c | 296 -- > lib/rwsem.c| 293 -- > lib/spinlock_debug.c | 302 -- > kernel/locking/Makefile| 25 > kernel/locking/lglock.c| 89 > kernel/locking/lockdep.c | 4257 +++ > kernel/locking/lockdep_internals.h | 170 + > kernel/locking/lockdep_proc.c | 683 + > kernel/locking/lockdep_states.h|9 > kernel/locking/mutex-debug.c | 110 > kernel/locking/mutex-debug.h | 55 > kernel/locking/mutex.c | 960 +++ > kernel/locking/mutex.h | 48 > kernel/locking/percpu-rwsem.c | 165 + > kernel/locking/rtmutex-debug.c | 187 + > kernel/locking/rtmutex-debug.h | 33 > kernel/locking/rtmutex-tester.c| 420 +++ > kernel/locking/rtmutex.c | 1060 > kernel/locking/rtmutex.h | 26 > kernel/locking/rtmutex_common.h| 126 + > kernel/locking/rwsem-spinlock.c| 296 ++ > kernel/locking/rwsem-xadd.c| 293 ++ > kernel/locking/rwsem.c | 157 + > kernel/locking/semaphore.c | 263 ++ > kernel/locking/spinlock.c | 399 +++ > kernel/locking/spinlock_debug.c| 302 ++ > kernel/Makefile| 22 > kernel/futex.c |2 > lib/Makefile |4 > 48 files changed, 10138 insertions(+), 10131 deletions(-) > > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 0/8] Move locking primitives into kernel/locking/
On Tue, Nov 05, 2013 at 01:10:44PM +0100, Peter Zijlstra wrote: Hi all, During Kernel Summit Dave mentioned that there wasn't a clear maintainer for locking bits. To remedy this Ingo suggested gathering all the various locking primitives and lockdep into a single place: kernel/locking/. I would further like to propose a MAINTAINERS entry like: LOCKING M: Ingo Molnar mi...@redhat.com M: Peter Zijlstra pet...@infradead.org M:Oleg Nesterov o...@redhat.com M:Paul E. McKenney paul...@linux.vnet.ibm.com M:Linus Torvalds torva...@linux-foundation.org T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git locking/core S: Maintained F: kernel/locking/ Because for most 'fun' locking discussions we usually end up with at least those people anyway :-) Comments? OK, I am in. How are we organizing this? I could imagine divvying up the various types of locks, having a minimum number of reviews or acks coupled with a maximum review time, or just requiring the full set of reviews and acks given the criticality of locking code. Other approaches? Thanx, Paul --- kernel/lglock.c| 89 kernel/lockdep.c | 4257 --- kernel/lockdep_internals.h | 170 - kernel/lockdep_proc.c | 683 - kernel/lockdep_states.h|9 kernel/mutex-debug.c | 110 kernel/mutex-debug.h | 55 kernel/mutex.c | 960 --- kernel/mutex.h | 48 kernel/rtmutex-debug.c | 187 - kernel/rtmutex-debug.h | 33 kernel/rtmutex-tester.c| 420 --- kernel/rtmutex.c | 1060 kernel/rtmutex.h | 26 kernel/rtmutex_common.h| 126 - kernel/rwsem.c | 157 - kernel/semaphore.c | 263 -- kernel/spinlock.c | 399 --- lib/percpu-rwsem.c | 165 - lib/rwsem-spinlock.c | 296 -- lib/rwsem.c| 293 -- lib/spinlock_debug.c | 302 -- kernel/locking/Makefile| 25 kernel/locking/lglock.c| 89 kernel/locking/lockdep.c | 4257 +++ kernel/locking/lockdep_internals.h | 170 + kernel/locking/lockdep_proc.c | 683 + kernel/locking/lockdep_states.h|9 kernel/locking/mutex-debug.c | 110 kernel/locking/mutex-debug.h | 55 kernel/locking/mutex.c | 960 +++ kernel/locking/mutex.h | 48 kernel/locking/percpu-rwsem.c | 165 + kernel/locking/rtmutex-debug.c | 187 + kernel/locking/rtmutex-debug.h | 33 kernel/locking/rtmutex-tester.c| 420 +++ kernel/locking/rtmutex.c | 1060 kernel/locking/rtmutex.h | 26 kernel/locking/rtmutex_common.h| 126 + kernel/locking/rwsem-spinlock.c| 296 ++ kernel/locking/rwsem-xadd.c| 293 ++ kernel/locking/rwsem.c | 157 + kernel/locking/semaphore.c | 263 ++ kernel/locking/spinlock.c | 399 +++ kernel/locking/spinlock_debug.c| 302 ++ kernel/Makefile| 22 kernel/futex.c |2 lib/Makefile |4 48 files changed, 10138 insertions(+), 10131 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 0/8] Move locking primitives into kernel/locking/
On Tue, Nov 5, 2013 at 4:10 AM, Peter Zijlstra wrote: > Hi all, > > During Kernel Summit Dave mentioned that there wasn't a clear maintainer for > locking bits. > > To remedy this Ingo suggested gathering all the various locking primitives and > lockdep into a single place: kernel/locking/. I quite like the idea. > I would further like to propose a MAINTAINERS entry like: > > LOCKING > M: Ingo Molnar > M: Peter Zijlstra > M: Oleg Nesterov > M: "Paul E. McKenney" > M: Linus Torvalds > T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git > locking/core > S: Maintained > F: kernel/locking/ > > Because for most 'fun' locking discussions we usually end up with at least > those people anyway :-) Agree :) While I don't think I carry as much weight as these people, I was going to ask to be included here for the fun discussions - and then I realized that having a separate directory for these files makes it super easy to set up a mail filter anyway :) -- Michel "Walken" Lespinasse A program is never fully debugged until the last user dies. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 0/8] Move locking primitives into kernel/locking/
On Tue, 5 Nov 2013 14:26:09 +0100 Ingo Molnar wrote: > > * Steven Rostedt wrote: > > Also, 'kernel lock' brings me back memories of the 'big kernel lock' - > while 'kernel locks' brings verb/noun ambiguity and visuals of > 'kernel locks up'. Of course "locking" is only a verb, and we get "kernel locking up" too ;-) > > As for typing legth: kernel/lo autocompletion is your friend! :-) > > All in one, I think kernel/locking/ is a better name. Fine, but I just love the idea of having the choice between a bagel and cream cheese or with kernel lox. -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 0/8] Move locking primitives into kernel/locking/
On Tue, 05 Nov 2013 14:21:38 +0100 Maarten Lankhorst wrote: > Congratulations! You're our early bikeshed winner for today. Please pick your > favorite color at http://bikeshed.com Has nothing to do with bikesheds, but more to do with bagel shops! -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 0/8] Move locking primitives into kernel/locking/
* Steven Rostedt wrote: > On Tue, 05 Nov 2013 13:10:44 +0100 > Peter Zijlstra wrote: > > > Hi all, > > > > During Kernel Summit Dave mentioned that there wasn't a clear maintainer for > > locking bits. > > > > To remedy this Ingo suggested gathering all the various locking primitives > > and > > lockdep into a single place: kernel/locking/. > > > > I would further like to propose a MAINTAINERS entry like: > > > > LOCKING > > M: Ingo Molnar > > M: Peter Zijlstra > > M: Oleg Nesterov > > M: "Paul E. McKenney" > > M: Linus Torvalds > > T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git > > locking/core > > S: Maintained > > F: kernel/locking/ > > I wonder if it should be called kernel/locks, as that's less to type, > smaller path names, and tastes good on bagels. The subsystem and topic is generally called 'kernel locking' though, and that's what the tree branches have been called for the past couple of years as well. Also, 'kernel lock' brings me back memories of the 'big kernel lock' - while 'kernel locks' brings verb/noun ambiguity and visuals of 'kernel locks up'. As for typing legth: kernel/lo autocompletion is your friend! :-) All in one, I think kernel/locking/ is a better name. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 0/8] Move locking primitives into kernel/locking/
op 05-11-13 14:18, Steven Rostedt schreef: > On Tue, 05 Nov 2013 13:10:44 +0100 > Peter Zijlstra wrote: > >> Hi all, >> >> During Kernel Summit Dave mentioned that there wasn't a clear maintainer for >> locking bits. >> >> To remedy this Ingo suggested gathering all the various locking primitives >> and >> lockdep into a single place: kernel/locking/. >> >> I would further like to propose a MAINTAINERS entry like: >> >> LOCKING >> M: Ingo Molnar >> M: Peter Zijlstra >> M: Oleg Nesterov >> M: "Paul E. McKenney" >> M: Linus Torvalds >> T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git >> locking/core >> S: Maintained >> F: kernel/locking/ > I wonder if it should be called kernel/locks, as that's less to type, > smaller path names, and tastes good on bagels. > > -- Steve > Congratulations! You're our early bikeshed winner for today. Please pick your favorite color at http://bikeshed.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 0/8] Move locking primitives into kernel/locking/
On Tue, 05 Nov 2013 13:10:44 +0100 Peter Zijlstra wrote: > Hi all, > > During Kernel Summit Dave mentioned that there wasn't a clear maintainer for > locking bits. > > To remedy this Ingo suggested gathering all the various locking primitives and > lockdep into a single place: kernel/locking/. > > I would further like to propose a MAINTAINERS entry like: > > LOCKING > M: Ingo Molnar > M: Peter Zijlstra > M:Oleg Nesterov > M:"Paul E. McKenney" > M:Linus Torvalds > T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git > locking/core > S: Maintained > F: kernel/locking/ I wonder if it should be called kernel/locks, as that's less to type, smaller path names, and tastes good on bagels. -- Steve > > Because for most 'fun' locking discussions we usually end up with at least > those people anyway :-) > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC 0/8] Move locking primitives into kernel/locking/
Hi all, During Kernel Summit Dave mentioned that there wasn't a clear maintainer for locking bits. To remedy this Ingo suggested gathering all the various locking primitives and lockdep into a single place: kernel/locking/. I would further like to propose a MAINTAINERS entry like: LOCKING M: Ingo Molnar M: Peter Zijlstra M: Oleg Nesterov M: "Paul E. McKenney" M: Linus Torvalds T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git locking/core S: Maintained F: kernel/locking/ Because for most 'fun' locking discussions we usually end up with at least those people anyway :-) Comments? --- kernel/lglock.c| 89 kernel/lockdep.c | 4257 --- kernel/lockdep_internals.h | 170 - kernel/lockdep_proc.c | 683 - kernel/lockdep_states.h|9 kernel/mutex-debug.c | 110 kernel/mutex-debug.h | 55 kernel/mutex.c | 960 --- kernel/mutex.h | 48 kernel/rtmutex-debug.c | 187 - kernel/rtmutex-debug.h | 33 kernel/rtmutex-tester.c| 420 --- kernel/rtmutex.c | 1060 kernel/rtmutex.h | 26 kernel/rtmutex_common.h| 126 - kernel/rwsem.c | 157 - kernel/semaphore.c | 263 -- kernel/spinlock.c | 399 --- lib/percpu-rwsem.c | 165 - lib/rwsem-spinlock.c | 296 -- lib/rwsem.c| 293 -- lib/spinlock_debug.c | 302 -- kernel/locking/Makefile| 25 kernel/locking/lglock.c| 89 kernel/locking/lockdep.c | 4257 +++ kernel/locking/lockdep_internals.h | 170 + kernel/locking/lockdep_proc.c | 683 + kernel/locking/lockdep_states.h|9 kernel/locking/mutex-debug.c | 110 kernel/locking/mutex-debug.h | 55 kernel/locking/mutex.c | 960 +++ kernel/locking/mutex.h | 48 kernel/locking/percpu-rwsem.c | 165 + kernel/locking/rtmutex-debug.c | 187 + kernel/locking/rtmutex-debug.h | 33 kernel/locking/rtmutex-tester.c| 420 +++ kernel/locking/rtmutex.c | 1060 kernel/locking/rtmutex.h | 26 kernel/locking/rtmutex_common.h| 126 + kernel/locking/rwsem-spinlock.c| 296 ++ kernel/locking/rwsem-xadd.c| 293 ++ kernel/locking/rwsem.c | 157 + kernel/locking/semaphore.c | 263 ++ kernel/locking/spinlock.c | 399 +++ kernel/locking/spinlock_debug.c| 302 ++ kernel/Makefile| 22 kernel/futex.c |2 lib/Makefile |4 48 files changed, 10138 insertions(+), 10131 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC 0/8] Move locking primitives into kernel/locking/
Hi all, During Kernel Summit Dave mentioned that there wasn't a clear maintainer for locking bits. To remedy this Ingo suggested gathering all the various locking primitives and lockdep into a single place: kernel/locking/. I would further like to propose a MAINTAINERS entry like: LOCKING M: Ingo Molnar mi...@redhat.com M: Peter Zijlstra pet...@infradead.org M: Oleg Nesterov o...@redhat.com M: Paul E. McKenney paul...@linux.vnet.ibm.com M: Linus Torvalds torva...@linux-foundation.org T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git locking/core S: Maintained F: kernel/locking/ Because for most 'fun' locking discussions we usually end up with at least those people anyway :-) Comments? --- kernel/lglock.c| 89 kernel/lockdep.c | 4257 --- kernel/lockdep_internals.h | 170 - kernel/lockdep_proc.c | 683 - kernel/lockdep_states.h|9 kernel/mutex-debug.c | 110 kernel/mutex-debug.h | 55 kernel/mutex.c | 960 --- kernel/mutex.h | 48 kernel/rtmutex-debug.c | 187 - kernel/rtmutex-debug.h | 33 kernel/rtmutex-tester.c| 420 --- kernel/rtmutex.c | 1060 kernel/rtmutex.h | 26 kernel/rtmutex_common.h| 126 - kernel/rwsem.c | 157 - kernel/semaphore.c | 263 -- kernel/spinlock.c | 399 --- lib/percpu-rwsem.c | 165 - lib/rwsem-spinlock.c | 296 -- lib/rwsem.c| 293 -- lib/spinlock_debug.c | 302 -- kernel/locking/Makefile| 25 kernel/locking/lglock.c| 89 kernel/locking/lockdep.c | 4257 +++ kernel/locking/lockdep_internals.h | 170 + kernel/locking/lockdep_proc.c | 683 + kernel/locking/lockdep_states.h|9 kernel/locking/mutex-debug.c | 110 kernel/locking/mutex-debug.h | 55 kernel/locking/mutex.c | 960 +++ kernel/locking/mutex.h | 48 kernel/locking/percpu-rwsem.c | 165 + kernel/locking/rtmutex-debug.c | 187 + kernel/locking/rtmutex-debug.h | 33 kernel/locking/rtmutex-tester.c| 420 +++ kernel/locking/rtmutex.c | 1060 kernel/locking/rtmutex.h | 26 kernel/locking/rtmutex_common.h| 126 + kernel/locking/rwsem-spinlock.c| 296 ++ kernel/locking/rwsem-xadd.c| 293 ++ kernel/locking/rwsem.c | 157 + kernel/locking/semaphore.c | 263 ++ kernel/locking/spinlock.c | 399 +++ kernel/locking/spinlock_debug.c| 302 ++ kernel/Makefile| 22 kernel/futex.c |2 lib/Makefile |4 48 files changed, 10138 insertions(+), 10131 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 0/8] Move locking primitives into kernel/locking/
On Tue, 05 Nov 2013 13:10:44 +0100 Peter Zijlstra pet...@infradead.org wrote: Hi all, During Kernel Summit Dave mentioned that there wasn't a clear maintainer for locking bits. To remedy this Ingo suggested gathering all the various locking primitives and lockdep into a single place: kernel/locking/. I would further like to propose a MAINTAINERS entry like: LOCKING M: Ingo Molnar mi...@redhat.com M: Peter Zijlstra pet...@infradead.org M:Oleg Nesterov o...@redhat.com M:Paul E. McKenney paul...@linux.vnet.ibm.com M:Linus Torvalds torva...@linux-foundation.org T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git locking/core S: Maintained F: kernel/locking/ I wonder if it should be called kernel/locks, as that's less to type, smaller path names, and tastes good on bagels. -- Steve Because for most 'fun' locking discussions we usually end up with at least those people anyway :-) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 0/8] Move locking primitives into kernel/locking/
op 05-11-13 14:18, Steven Rostedt schreef: On Tue, 05 Nov 2013 13:10:44 +0100 Peter Zijlstra pet...@infradead.org wrote: Hi all, During Kernel Summit Dave mentioned that there wasn't a clear maintainer for locking bits. To remedy this Ingo suggested gathering all the various locking primitives and lockdep into a single place: kernel/locking/. I would further like to propose a MAINTAINERS entry like: LOCKING M: Ingo Molnar mi...@redhat.com M: Peter Zijlstra pet...@infradead.org M: Oleg Nesterov o...@redhat.com M: Paul E. McKenney paul...@linux.vnet.ibm.com M: Linus Torvalds torva...@linux-foundation.org T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git locking/core S: Maintained F: kernel/locking/ I wonder if it should be called kernel/locks, as that's less to type, smaller path names, and tastes good on bagels. -- Steve Congratulations! You're our early bikeshed winner for today. Please pick your favorite color at http://bikeshed.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 0/8] Move locking primitives into kernel/locking/
* Steven Rostedt rost...@goodmis.org wrote: On Tue, 05 Nov 2013 13:10:44 +0100 Peter Zijlstra pet...@infradead.org wrote: Hi all, During Kernel Summit Dave mentioned that there wasn't a clear maintainer for locking bits. To remedy this Ingo suggested gathering all the various locking primitives and lockdep into a single place: kernel/locking/. I would further like to propose a MAINTAINERS entry like: LOCKING M: Ingo Molnar mi...@redhat.com M: Peter Zijlstra pet...@infradead.org M: Oleg Nesterov o...@redhat.com M: Paul E. McKenney paul...@linux.vnet.ibm.com M: Linus Torvalds torva...@linux-foundation.org T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git locking/core S: Maintained F: kernel/locking/ I wonder if it should be called kernel/locks, as that's less to type, smaller path names, and tastes good on bagels. The subsystem and topic is generally called 'kernel locking' though, and that's what the tree branches have been called for the past couple of years as well. Also, 'kernel lock' brings me back memories of the 'big kernel lock' - while 'kernel locks' brings verb/noun ambiguity and visuals of 'kernel locks up'. As for typing legth: kernel/loTab autocompletion is your friend! :-) All in one, I think kernel/locking/ is a better name. Thanks, Ingo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 0/8] Move locking primitives into kernel/locking/
On Tue, 05 Nov 2013 14:21:38 +0100 Maarten Lankhorst maarten.lankho...@canonical.com wrote: Congratulations! You're our early bikeshed winner for today. Please pick your favorite color at http://bikeshed.com Has nothing to do with bikesheds, but more to do with bagel shops! -- Steve -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 0/8] Move locking primitives into kernel/locking/
On Tue, 5 Nov 2013 14:26:09 +0100 Ingo Molnar mi...@kernel.org wrote: * Steven Rostedt rost...@goodmis.org wrote: Also, 'kernel lock' brings me back memories of the 'big kernel lock' - while 'kernel locks' brings verb/noun ambiguity and visuals of 'kernel locks up'. Of course locking is only a verb, and we get kernel locking up too ;-) As for typing legth: kernel/loTab autocompletion is your friend! :-) All in one, I think kernel/locking/ is a better name. Fine, but I just love the idea of having the choice between a bagel and cream cheese or with kernel lox. -- Steve -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 0/8] Move locking primitives into kernel/locking/
On Tue, Nov 5, 2013 at 4:10 AM, Peter Zijlstra pet...@infradead.org wrote: Hi all, During Kernel Summit Dave mentioned that there wasn't a clear maintainer for locking bits. To remedy this Ingo suggested gathering all the various locking primitives and lockdep into a single place: kernel/locking/. I quite like the idea. I would further like to propose a MAINTAINERS entry like: LOCKING M: Ingo Molnar mi...@redhat.com M: Peter Zijlstra pet...@infradead.org M: Oleg Nesterov o...@redhat.com M: Paul E. McKenney paul...@linux.vnet.ibm.com M: Linus Torvalds torva...@linux-foundation.org T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git locking/core S: Maintained F: kernel/locking/ Because for most 'fun' locking discussions we usually end up with at least those people anyway :-) Agree :) While I don't think I carry as much weight as these people, I was going to ask to be included here for the fun discussions - and then I realized that having a separate directory for these files makes it super easy to set up a mail filter anyway :) -- Michel Walken Lespinasse A program is never fully debugged until the last user dies. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
