Re: [PATCH] SMP initialization: detection and enumeration

[Samuel Thibault]

Almudena Garcia, le mar. 28 juil. 2020 10:27:55 +0200, a ecrit:
> > Simply return rather than using a variable.
> I prefer using a temporary variable to ease debugging in case of error. Direct
> return can be difficult to debug in this case.

That's alright while debugging. But before we commit the source code, we
need it to be in a way which is the most readable, so people can easily
work it out.

> > You can just return it.
> I prefer to avoid multiple return, to ease the reading. A single return can be
> easy to read.

? No. Introducing a variable, remembering that it holds a value, and
eventually returning it, is much more brain overhead than just directly
returning the value.

Also, having a few returns early in the function, to eliminate the error
cases and trivial cases, allows to get rid of that from the mind, and
focus on the real stuff for the rest of the function.

> > So you picked it up from somewhere?
> > Since it's a BSD license it is fine, just making sure that it is the
> > proper copyright notice.
> 
> This file existed in older versions of gnumach. Thomas removed It in 2007.
> Simply, I recovered It and updated.
> [1]http://git.savannah.gnu.org/cgit/hurd/gnumach.git/tree/i386/imps/apic.h?id=
> f20666fc6b0471738829363e20c27f282f65dbf2

Oh, interesting, it dates back so long ago :)

> > I'm wondering: is it really *that* simple to get the current cpu number,
> > just read a memory location?  I'm surprised that this would provide
> > different results on different cpus.
> 
> The APIC ID is stored in the Local APIC of each cpu. This address is common 
> for
> all Local APIC: accessing this from each cpu, it shows the Local APIC of this
> cpu.
> By example, if you access this address from cpu1, you can see the Local APIC 
> of
> cpu1.

So it's a special address whose accesses are trapped within the chip and
don't actually get out on the memory bus?

Samuel