On Thu, Mar 15, 2018 at 12:27 AM Joel Sherrill <j...@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.hu...@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.hu...@embedded-brains.de >> PGP : Public key available on request. >> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. >> _______________________________________________ >> devel mailing list >> devel@rtems.org >> http://lists.rtems.org/mailman/listinfo/devel _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
