[Trimming the Cc list, and adding George, which I did not realize he was not there!]
On Fri, 2015-10-30 at 11:00 -0600, Jan Beulich wrote: > > > > On 30.10.15 at 17:33, <dario.faggi...@citrix.com> wrote: > > Are you saying that we shouldn't make the change at all? Or that we > > should make the change and also turn the BUG_ON() (the one that is > > left > > in place) into an ASSERT()? Or that we should not mark the function > > as > > 'inline'? > > No, I'm suggesting that instead of this change the BUG_ON() (or > perhaps both and also others) should be converted to ASSERT(). > I'm all in favour of turning these two (if both are staying) BUG_ON()s in ASSERT()s. What I especially don't like of the function right now, is that by looking at the prototype, and at least at some of the call sites, it feels like it is possible to insert a vCPU v in the runqueue of an arbitrary pCPU, while that must always happens in v->processor's runqueue. That is why I'd like to be able to remove that cpu argument. Perhaps avoiding inlining can really be considered? Looking at history, the function was shorter and called less times when originally developed and marked as such. I'm not sure that's still a good thing... Regards, Dario -- <<This happens because I choose it to happen!>> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
