* Paul E. McKenney <paulmck@xxxxxxxxxxxxxxxxxx> wrote: > > > > I'm CC'ing Paul and Mathieu as well for urcu. > > I am hoping we can get better convergence between the user-level > and kernel-level URCU implementations once I get SRCU merged into > the TREE_RCU and TINY_RCU implementations. [...] Yeah. > [...] But it is early days for user-level RCU implementations -- > for example, the kernel-level implementations have deep > dependencies on being able to lock themselves cheaply to a given > CPU, which does not exist at user level. Correct - this is why i suggested a plain copy first, then look back how we (and whether we!) want to share logic. > But there seems to be an assumption that there should be only one > URCU implementation, and I am not sure that this assumption holds. I'm not sure about that either. And sice tools/kvm/ lives in the kernel repo it would be a mortal sin [*] to not explore the code sharing angle!!! :-) If a reasonable amount of sharing of logic is possible without making it painful for the kernel RCU code we could do other nice things like change the RCU logic and test it in user-space first and run user-space rcutorture on some really big cluster. > [ ... ] > > All that aside, one advantage of http://lttng.org/urcu is that it > already exists, which allows prototyping to proceed immediately. it's offline right now: $ git clone git://git.lttng.org/urcu Cloning into urcu... fatal: The remote end hung up unexpectedly One complication is that it's LGPL while tools/kvm/ is GPLv2. I guess we could copy a suitable implementation into tools/kvm/rcu/? Thanks, Ingo [1] punishable by death or eternal hacking of a Windows driver (i'd pick the former) -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
