* Paul E. McKenney <[EMAIL PROTECTED]> wrote: > For the patch, here are my questions: > > o What is the best way to select between classic RCU and this > scheme? > > 1. Massive #ifdef across rcupdate.c > > 2. Create an rcupdate_rt.c and browbeat the build system > into picking one or the other (no clue if this is > possible...) > > 3. Create an rcupdate_rt.c and rely on the linker to pick > one or the other, with rcupdate.h generating different > external symbol names to make the choice.
you can also go for option #0: just replace the existing RCU code with the new one, and i'll then deal with the configuration details. what will have to happen is most likely #2 (since there is near zero code sharing between the two variants, right?). Picking rcupdate_rt.c is as simple as doing this: obj-$(CONFIG_DONT_PREEMPT_RCU) += rcupdate.o obj-$(CONFIG_PREEMPT_RCU) += rcupdate_rt.o and then use Kconfig to generate either CONFIG_DONT_PREEMPT_RCU (default) or CONFIG_PREEMPT_RCU (if the user selects it). but it's not yet clear whether we want to offer this to users as a configurable option. The simplest solution for you would be to go with option #0 :-) [or if you prefer switchability, #1 is good too - i can then extract the bits and do #2 based on that.] > o How best to interface to OOM? Left to myself, I leave this > for later. ;-) yeah, i'd not worry about OOM that much at this stage. > I will take the cowardly approach of patching against the upstream > kernel. sure. This is in fact easier for me: i'll first rip all my RCU hackery out of -RT and then add your code, so the base i'll be merging against will be closer to upstream than to current -RT. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/