On Wed, 11 Dec 2013, Ingo Molnar wrote:
> > Thinking about this some more: Separating these two issues would
> > make it impossible to build x86 since the hackery in
> > x86/include/asm/preempt.h depends on having the right names in
> > x86/include/asm/percpu.h. Changing the names first would resu
* Christoph Lameter wrote:
> On Wed, 11 Dec 2013, Ingo Molnar wrote:
>
> > > Well this is how the x86 portions came from Peter. [...]
> >
> > That's an interesting piece of information, in particular because
> > you lost From: PeterZ authorship there, don't do that!
>
> Ok will add that. Ther
On Wed, 11 Dec 2013, Ingo Molnar wrote:
> > Well this is how the x86 portions came from Peter. [...]
>
> That's an interesting piece of information, in particular because you
> lost From: PeterZ authorship there, don't do that!
Ok will add that. There is a signoff there. Is that ok with you Peter
* Christoph Lameter wrote:
> On Tue, 10 Dec 2013, Ingo Molnar wrote:
>
> > By what is this required - by the previous patch #13?
>
> Yes its required in order to keep the __this_cpu ops working.
>
> > Also, the changelog indicates it's two changes - please split the
> > patch in two if so.
>
On Tue, 10 Dec 2013, Ingo Molnar wrote:
> By what is this required - by the previous patch #13?
Yes its required in order to keep the __this_cpu ops working.
> Also, the changelog indicates it's two changes - please split the
> patch in two if so.
Well this is how the x86 portions came from Pet
Hello,
On Tue, Dec 10, 2013 at 07:31:34PM +0100, Ingo Molnar wrote:
> (Tejun, please wait for this review to be complete before committing
> anything.)
Eh... alright, backing out the patch. Please let me know when things
are ready.
Thanks.
--
tejun
--
To unsubscribe from this list: send the
* Christoph Lameter wrote:
> On Tue, 10 Dec 2013, Ingo Molnar wrote:
>
> > > Yeah, trying to figure out which should go through which tree.
> > > Christoph, should I also pickup 14? Or can that go through x86?
> >
> > Well, it appears to have dependencies so I doubt it can be kept
> > separate
On Tue, 10 Dec 2013, Ingo Molnar wrote:
> > Yeah, trying to figure out which should go through which tree.
> > Christoph, should I also pickup 14? Or can that go through x86?
>
> Well, it appears to have dependencies so I doubt it can be kept
> separate. In any case, provided all debugging is pro
On Tue, 10 Dec 2013, Tejun Heo wrote:
> > as we don't want to expand percpu ops without doing proper debugging.
>
> Yeah, trying to figure out which should go through which tree.
> Christoph, should I also pickup 14? Or can that go through x86?
If you do that then you need to also pick up the pa
* Tejun Heo wrote:
> On Tue, Dec 10, 2013 at 04:45:06PM +0100, Ingo Molnar wrote:
> >
> > * Tejun Heo wrote:
> >
> > > On Tue, Dec 03, 2013 at 05:32:45PM -0600, Christoph Lameter wrote:
> > > > The patches following this one will add preemption checks to __this_cpu
> > > > ops so we need to h
On Tue, Dec 10, 2013 at 04:45:06PM +0100, Ingo Molnar wrote:
>
> * Tejun Heo wrote:
>
> > On Tue, Dec 03, 2013 at 05:32:45PM -0600, Christoph Lameter wrote:
> > > The patches following this one will add preemption checks to __this_cpu
> > > ops so we need to have an alternative way to use this_c
* Tejun Heo wrote:
> On Tue, Dec 03, 2013 at 05:32:45PM -0600, Christoph Lameter wrote:
> > The patches following this one will add preemption checks to __this_cpu
> > ops so we need to have an alternative way to use this_cpu operations
> > without preemption checks.
> >
> > raw_cpu_ops will be
On Tue, Dec 03, 2013 at 05:32:45PM -0600, Christoph Lameter wrote:
> The patches following this one will add preemption checks to __this_cpu
> ops so we need to have an alternative way to use this_cpu operations
> without preemption checks.
>
> raw_cpu_ops will be the basis for all other ops since
The patches following this one will add preemption checks to __this_cpu
ops so we need to have an alternative way to use this_cpu operations
without preemption checks.
raw_cpu_ops will be the basis for all other ops since these will be the
operations that do not implement any checks.
Primitive o
14 matches
Mail list logo
