Re: [PATCH] SMP initialization: detection and enumeration

[Almudena Garcia]

> 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.

Ok, then I will modify my code this way.

> ? 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.

Same

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 it's a special address whose accesses are trapped within the chip and

> don't actually get out on the memory bus?

I don't know the technical details at all. In OSDev (https://wiki.osdev.org/APIC) It explains this:

The local APIC's registers are memory-mapped in physical page FEE00xxx (as seen in table 8-1 of Intel P4 SPG). This address is the same for each local APIC that exists in a configuration, meaning you are only able to directly access the registers of the local APIC of the core that your code is currently executing on.

The physical address is not always the same: each machine can map the Local APIC in a different address. By this reason, I search It in ACPI tables, in MADT (APIC) table.

Thanks for your review :) . This weekend I will try to fix the code.

El jue., 30 jul. 2020 a las 22:44, Samuel Thibault (<samuel.thibault@gnu.org>) escribió:

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