Messages in this thread | | | Subject | Re: [PATCH 0/3] jump label: updates for 2.6.37 | From | Steven Rostedt <> | Date | Tue, 23 Nov 2010 16:42:07 -0500 |
| |
On Tue, 2010-11-23 at 16:27 -0500, Jason Baron wrote: > Hi, > > A few jump label patches that I want considered for 2.6.37. Patches are against > the latest -tip tree.
I can see patch 2 and 3 going to 2.6.37, but patch 1 seems a bit too big. If it is not a true fix for anything and is just a design change, then lets hold off till 2.6.38.
> > The first one, which adds 'state' to the jump label mechanism is the most > important. Essentially, it ensures that if jump labels are enabled/disabled in > the core kernel but the actual call sites are in modules, we properly honor the > state of the jump label. This also works for jump labels which may be defined in > one module but made use of in another module.
What happens if we don't do this. What does "honoring" the state actually mean?
> > There has been some discussion about using the 'key' variable to store the > enabled/disabled state for each jump label. However, I think a better design > will be to use the 'key' variable to store a pointer to the appropriate jump > label tables. In this way, we can enable/disable jump labels, without the > hashing that I'm currently doing. However, I didn't want to propose these more > invasive changes until 2.6.38.
I'm thinking even patch 1 is too invasive. Unless it crashes or truly breaks something without the change.
Patch 2 is small and reasonable, and patch 3 is just documentation changes. Both OK for an -rc update.
-- Steve
| |