[Bug 1607] __RTEMS_SIZEOF_VOID_P__ flawed design

[bugzilla-daemon at rtems.org]

https://www.rtems.org/bugzilla/show_bug.cgi?id=1607

Chris Johns <chrisj at rtems.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |chrisj at rtems.org

--- Comment #28 from Chris Johns <chrisj at rtems.org> 2010-07-19 21:32:31 CDT ---
The tone of the thread in this PR is unfortunate. I hope we can restart with
all parties involved so we can work towards a suitable solution. We need to as
RTEMS needs to support SMP and this means support for per-CPU data.

Reviewing this thread it is clear to me we are missing the requirements and
design documentation that drives the implementation. There have been a handful
of implementations that address some specific issues but no one can clearly
state they address all issues in all cases. This post is an attempt to start
the definition process.

The per-CPU data needs to be defined outside of the language and
implementation. Sebastian has stated this a couple of times and I am in full
agreement. The per-CPU data needs to be an ABI and it needs to be formally
specified like any other ABI. A C struct is no good as a definition of an ABI.
It may be used to implement an ABI but it cannot be the definition and cannot
be exported as one.

We need to include in the ABI all data used by SMP and critical processing code
that needs to be accessed across language barriers (specifically we have C and
assembler). There needs to be an ABI for each target or CPU type supported by
RTEMS. A target's ABI may be split into various ABI's for each multilib variant
supported if a single common target ABI is not possible. This is a specific
detail that is the concern of that specific CPU.

The SMP per-CPU ABI is closed to a running system. It is not something that
needs to be common to all targets, nor does it need to be exported or imported.
The ABI is required to be stable over a major release of RTEMS. It must be
invariant for each version of GCC (all involved tools) that the RTEMS major
version supports and all options the specific CPU variant supports for that GCC
version.

We also need to define a clear API to accessing the fields of the SMP per-CPU
data. I suggest this be defined for each language (C and assembler) currently
used to access this data. All access must be via this API for code in the
cpukit (and maybe libcpu). We may decide to export this API and the resulting
internal methods we use to implement the ABI as a convenience to our users.
This rules out direct access to a structure. A structure can be used to
implement the ABI but it is not the supported API.

All this means if I am given a binary RTEMS library for a specific CPU variant
I must be able to determine from RTEMS documentation the per-CPU data. How I
decide to implement accessing that data is up to me.

On to possible implementation ideas. If we have a set ABI we can just define
the offsets and the size of the data. This removes the need for autoconf tests.
I suspect I may have suggested using autoconf as a method of detecting offsets
and I apologize. It is clear to me this is not needed and a distraction.

There has also been discussion about moving code to libcpu and libbsp. We have
users that have BSP code separate to RTEMS. If we move important code like IRQ
processing to libbsp and even libcpu we break the whole idea of the cpukit and
its role in RTEMS as a multilib binary interface. Every time we move out of the
cpukit to libcpu or libbsp we need to consider if this is a result of the
design choices made in that code. In the specific case of the SMP support, a
BSP may be required to fetch a CPU id or number of processors or some other
hardware specific detail. The cpukit code needs to define an API that the BSP
uses or provides. For example these could be external functions or tables of
handlers. If we have performance issues in critical code lets identify these
and then look for solutions. In the case of the CPU id it may be common to the
CPU family and therefore able to be placed in score/cpu tree. The details here
should work themselves out.

I hope this post is received in the positive way it is tended to be. I hope I
have most of the important bit correct but if I do not please feel free to
correct as I am sure you all will.

-- 
Configure bugmail: https://www.rtems.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.