Re: [PATCH 1/2] x86/head_64.S: Rename start_cpu()

* Borislav Petkov wrote: > On Tue, Mar 07, 2017 at 10:06:38AM +0100, Ingo Molnar wrote: > > The local labels syntax is silly, I always end up looking twice to make > > sense of > > 'Ljump' or 'Lwhatever' ;-) > > > > We cannot do anything about that - but we can name our symbols to work it >

Re: [PATCH 1/2] x86/head_64.S: Rename start_cpu()

On Tue, Mar 07, 2017 at 10:06:38AM +0100, Ingo Molnar wrote: > The local labels syntax is silly, I always end up looking twice to make sense > of > 'Ljump' or 'Lwhatever' ;-) > > We cannot do anything about that - but we can name our symbols to work it > around. > But the price is the extra un

Re: [PATCH 1/2] x86/head_64.S: Rename start_cpu()

* Borislav Petkov wrote: > From: Borislav Petkov > > It doesn't really start a CPU but does a far jump to C code. So call it > that. Eliminate the unconditional JMP to it from secondary_startup_64() > but make the jump to C code piece part of secondary_startup_64() > instead. > > Also, it doe

[PATCH 1/2] x86/head_64.S: Rename start_cpu()

From: Borislav Petkov It doesn't really start a CPU but does a far jump to C code. So call it that. Eliminate the unconditional JMP to it from secondary_startup_64() but make the jump to C code piece part of secondary_startup_64() instead. Also, it doesn't need to be a global symbol either so ma