cpukit/bspkit split.

[Sergei Organov]

Ralf Corsepius <ralf.corsepius at rtems.org> writes:
> On Fri, 2005-02-18 at 13:18 -0600, Joel Sherrill  wrote:
> > Sergei Organov wrote:
> > > "Joel Sherrill <joel at OARcorp.com>" <joel.sherrill at OARcorp.com> writes:
> > > 
> > >>Sergei Organov wrote:
> > >>
> > >>>"Joel Sherrill <joel at OARcorp.com>" <joel.sherrill at OARcorp.com> writes:

[...]

> I think: cpukit needs a much more restrictive API. Such kind of
> restrictive that it prevents cpukit from getting infected from "design
> warts" as the powerpc port apparently has been infected from.

Ideally, there should be exactly one "cpu.h" file in the entire RTEMS
source tree that is the property of cpukit and defines the cpukit
interface. All the ports then must implement this interface in their .c
and .S files.

However, such an approach makes it impossible to define CPU-dependent
compile-time constants that could be required to efficiently implement
parts of cpukit. Therefore, a reasonable approach would be to have
single "cpu.h" that has all the structures and routines declarations and
that at the end includes CPU-specific file, say, cpu_variant.h, that
exists for each CPU port and contains only allowed constants/defines.
The latter file is supposed to be rather short compared to the current
"cpu.h" files where a lot of defines could actually be replaced with
either functions or variables.

> 
> IMO, a point to getting started with this would be a fundamental
> redesign of rtems_cpu_table.

I don't think that fundamental redesign of rtems_cpu_table is in fact
required (see below).

> What I currently have in mind is implementing a class hierarchy
> similar to this:
> 
> RTEMSScoreCPUTable
> |
> +- RTEMSPowerpcCPUTable
> |  |
> |  +- RTEMSPowerpc<1>CPUTable
> |  +- RTEMSPowerpc<2>CPUTable
> |  .
> |  +- RTEMSPowerpc<M>CPUTable
> |
> +- RTEMSCPU<N>CPUTable
> .
> .
> 
> RTEMSScoreCPUTable would be "abstract base classes" implemented in
> cpukit/score, RTEMSCPU<N>CPUTable would be specializations to be
> implemented in cpukit/score/cpu/<CPU>
> 
> Finally, RTEMSCPU<N><M>CPUTable classes would be implemented in
> libcpu/cpu/<cpu>.
> 
> A traditional way to implement such kind of approach in C would be to
> apply "widget"-technology, as it is common in computer graphic.

There is a usual C++ way of implementing it (through vtable pointer),
though I think it's an overkill in this particular case of
rtems_cpu_table.

> 
> However, ATM, I don't see how this can be implemented in short term.

>From the above, the cpukit will know about and only about
RTEMSScoreCPUTable, right? If so, just move current rtems_cpu_table
declaration out of all those CPU-specific cpu.h files into a system-wide
cpu.h and change _CPU_Table to be of type pointer to rtems_cpu_table
(the latter is required to make it possible to do "inheritance"). [BTW,
I've never understood what's the purpose of copying of CPU table defined
in a BSP into a system-wide _CPU_Table ending up with two identical
copies].

system-wide/cpu.h:

typedef struct {
 ... all the current "required" fields ...
} rtems_cpu_table;

Then, if some CPU port needs something additional in the table, it could
be implemented like this (note that here cpu_variant.h is private to the
CPU port and is not seen by any generic source):

-- some-cpu/cpu_variant.h --

#include <system-wide/cpu.h>

/* Simple hand-made inheritance: */
typedef struct {
  rtems_cpu_table rtems;        /* Must be the first field */
  ... some CPU-specific fields ...
} rtems_cpu_variant_table;

-- some-cpu/bsp_start.c --

#include <some-cpu/cpu.h>

static rtems_cpu_variant_table cpuTable;

void bsp_start( void )
{
  ... fill cpuTable.rtems ...
  ... fill cpuTable CPU-specific fields ...
  ...
  rtems_initialize_executive( &BSP_Configuration, &cpuTable.rtems );
  ...
}

-- some-cpu/cpu.c --

void _CPU_Initialize(
  rtems_cpu_table  *cpu_table,
  void      (*thread_dispatch)
)
{
  /* Cast to the pointer to our specialized CPU table */
  rtems_cpu_variant_table* our_cpu_table =
    (rtems_cpu_variant_table*)cpu_table;

  ... do something with CPU-specific fields
      through 'our_cpu_table' pointer ...

  _CPU_Table = cpu_table;
}

BTW, the above 'rtems_cpu_variant_table' is indeed a kind of hand-made
"inheritance". Please notice that no fundamental redesign of
rtems_cpu_table is required.


-- 
Sergei.