[PATCH v2 0/3] Fix compiler errors for SMP on i386

[Amaan Cheval]

On Thu, Mar 15, 2018 at 12:27 AM Joel Sherrill <joel at rtems.org> wrote:

> Obviously not you Sebastian. :)

> Amaan.. what's your expectation of the overall status of SMP on pc386
> after these patches are added?

A compile-time error will still be thrown, but for anyone who wants to
tackle SMP issues on i386, they'll be able to pick up at what the
implementation currently lacks, instead of the "bitrot" that's occured as
the expectations of the RTEMS SMP system fell out of sync with the existing
i386-specific code.


> If something is "compile only" now, are there comments in the tickets
> indicating that? Is this clear from the git log messages? Is there
anywhere
> you got something compiling, but not working, in the code that might
> need a comment?

Patch 1 (CPU_Interrupt_frame's definition) is this way, and there's a
comment and it's mentioned in the commit message as well.
Patch 3 _may_ be thought of as that way - it only changes a macro to a
function, which does effectively the same thing (void body) - I'm not sure
that needs a comment left besides what was already there (and has been
preserved in the function as well).

----

The relevant tickets may benefit from some elaboration; the ticket this
patch series handles does mention that it's only to fix compile-time
issues, not logical implementation details[1]. The implementation details
that haven't been accounted for in patch 1 have the ticket in the error
message linked to [2], which I think has enough information to get one
started in the right direction, but I'll let you be the judge of that. (It
could benefit from direct links to the code, but given refactoring may
occur, pointing to a stale commit didn't seem any smarter than letting a
future undertaker just grep the codebase for the CPU_Interrupt_frame - I
might be wrong about that!)

[1] https://devel.rtems.org/ticket/3331#ticket
[2] https://devel.rtems.org/ticket/3335#ticket


> Just wanting to know what I should expect when I test these and
> ensure the next person who looks at these areas understands
> the status.

If you were to test this as-is, you'd still see a compile-time error with
the --enable-smp option, which we want. If you took the #error directive
out, though, you'd be free to tackle the implementation specific aspects
without having to first figure out seemingly unrelated errors. (Note that
if you have --enable-smp in first, then you "make clean", and try with
--disable-smp, that isn't enough. You need to start fresh.)


> --joel

> On Wed, Mar 14, 2018 at 1:55 AM, Sebastian Huber <
sebastian.huber at embedded-brains.de> wrote:

>> Who will review and check in i386-specific patches?

>> --
>> Sebastian Huber, embedded brains GmbH

>> Address : Dornierstr. 4, D-82178 Puchheim, Germany
>> Phone   : +49 89 189 47 41-16
>> Fax     : +49 89 189 47 41-09
>> E-Mail  : sebastian.huber at embedded-brains.de
>> PGP     : Public key available on request.

>> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.


>> _______________________________________________
>> devel mailing list
>> devel at rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel