cpukit/bspkit split.

[Sergei Organov]

"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:
> > [...]
> >
> 
> >>There is a PPC_INTERRUPTS_MAX which still remains to be addressed.
> >>Ralf.. I think the the MIPS defines that in libcpu as a variable used by the
> >>cpukit.
> > IMHO, it's time to define generic interface between cpukit and the rest
> > of RTEMS BSP that will ensure compile-time independence of cpukit, or at
> > least to document some guidelines. It seems that pre-multilib BSP
> > interface definitions don't address the issue as in fact every BSP is
> > now split between cpukit and the rest of libs and there is no definition
> > of the interface to be used on this split line. Does it sound
> > reasonable?
> 
> That largely exists.  When we started splitting the CPU kit from the BSP
> and libcpu parts of the tree, most of the ports were clean.

Guess those that didn't have any CPU variants or where CPU variations were
in fact insignificant? ;)

We can do the same for PowerPC, -- let every CPU variant be a separate
RTEMS port, i.e., just forget that they are all called PowerPCs, --
every BSP then will be pretty clean with respect to CPUkit split ;)

> The porting guide is in general pretty close.

Well, I'm looking at

<http://www.rtems.com/onlinedocs/doc-current/share/rtems/html/porting/index.html>

Do you mean this one? If so, I'm afraid it's far from being close. It
even doesn't mention anything like cpukit or bspkit and immediately
jumps to the reference to non-existing directory c/src/exec/score/cpu:

<http://www.rtems.com/onlinedocs/doc-current/share/rtems/html/porting/porting00004.html>

Then, "some_other_cpu_dependent_info" in the "rtems_cpu_table" seems
to be problematic as well.

Is there something more recent that I've missed?

[...]
> The rules for cpukit vs bspkit are actually quite simple. If gcc
> distinguishes a variant, then cpukit can know about it. If that
> variant is not detailed enough to distinguish two CPU cores that
> CPUkit has to know about, then we have to address that.
> The rub is that there seems to be one unique piece of the port for
> each architecture that you have to based on cpu model not ISA variant.

If we require CPUkit to have only code that is based on ISA variant,
then this problem goes away, right? That once again raises a question
how in fact the code is divided, why it is divided this way, and isn't
there a better way to divide it. All these questions could and should be
answered by designing the interface I'm speaking about.

> It might be number of interrupts or status register bits that are
> valid, etc, etc.

That's where the problem of undefined rules for splitting come into the
picture, IMHO. Where is the definition of the list of all the things
cpukit cares about? Is this list architecture dependent? Should it be
architecture dependent?

> Notice how the PowerPC port is evolving now. Ralf proposed some
> conditionals to remove/consolidate, then reduced the multilibs. Then
> everyone jumped in and said "you can remove that" or "why is that
> there?". Once the mess is straightened out, it will really be quite
> simple.

I'm afraid it won't be that simple anyway. Probably the number of
multilib variants will be reduced, but the question of figuring out the
exact interface between CPUkit and the rest of the system will remain.
Just try to put yourself on a place of a new programmer trying to
implement yet another CPU variant. Usually she will select a way of
least resistance and the situation will tend to return back where it is
now.

What I'm talking about is a [set of] '.h' file(s) that contains entire
CPUkit to the rest of BSPs interface and only that interface. There
should be defined not only what should go into the file(s), but with the
same significance what *must not* appear in this file(s). E.g., it
should be a documented requirement that there should be nothing but what
is actually required by the interface, -- especially no any #ifs that
can't be resolved by defines provided by the multilib variants.

Let's take a look at the current situation. Consider the authoritative
example of how things should be implemented, the "no_cpu" port. The
"cpu.h" seem to define the interface in question. It in turn includes
two more files, "no_cpu.h" and "types.h". I've carefully read all the
three and found no requirements in them that are violated by the current
PowerPC port's "cpu.h" and "powerpc.h". However, "powerpc.h" (as well as
"cpu.h") obviously violates CPUkit independence requirement as it uses
#ifdefs not supported by any of multilib variants. The bad thing is that
nothing in RTEMS documentation or no_cpu port suggests that it's broken.

Well, for me it seems that "no_cpu.h" and therefore "powerpc.h" should
be just eliminated altogether. Their purpose in cpukit is unclear and
comments in the no_cpu.h are misleading, IMHO.

Now comes a surprise: PowerPC port has in fact 2 "powerpc.h" files,

c/src/lib/libcpu/powerpc/rtems/powerpc/powerpc.h
cpukit/score/cpu/powerpc/rtems/score/powerpc.h

both claiming to be

/**
 * @file rtems/score/powerpc.h
 */

what's that? Did the former has been forgotten to be removed from the
CVS as it seems that it's the latter that ends up being installed?

> If everyone keeps offering constructive criticism and saying CPU X and Y
> should be able to use the same multilib, then we will make it.

That won't help to fix "powerpc.h", especially its mpc860 and mpc8260
interrupts definitions, I'm afraid. I think external (to the CPU core)
interrupts just shouldn't be there, -- only architecture-defined
exceptions. The fact that a PIC is built into the chip isn't an excuse
to put that vectors into this file.

This in turn once again raises a problem of absence of separate
raw-exception/c-exception/interrupt handlers/masks support in the
RTEMS-to-user and RTEMS-to-CPU APIs. Was there any progress in this area
recently?

> The next step will be getting help comparing .S files in various BSPs and
> seeing if we can consolidate them under fewer files. No one can test every
> variant but with care, we should be able to reduce them mechanically with
> little risk.

Yeah, at least that seems to be doable and will provide better starting
point for subsequent cleanups and enhancements.

-- 
Sergei.