cpukit/bspkit split.

[Joel Sherrill <joel@OARcorp.com>]

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:
>>>[...]
>>>
>>
>>>>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?

No.  The file referecnes need to be updated and the document needs to be 
updated to reflect that it is a CPU Kit porting guide.  Traditionally 
that was all you ported in RTEMS.

It captures the CPU dependent features the RTEMS proper code under 
cpukit needs to know about.

> [...]
> 
>>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.

The base point for why is easy.  It is at a minimum divided based upon 
the level of multilib distinctions gcc and newlib makes. We want cpukit/ 
to be multilib'ed using the same variants the *-rtems gcc/newlib 
binaries do.

There are n CPUs with a 603e/G2 core and gcc doesn't know ore care about 
the model names.  Ideally RTEMS cpukit/ wouldn't know either.

>>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?

The guidelines are architecture independent but the reality is that some 
things are defined by one ISA and left to the whims of the implementer 
on another.  On the MIPS for example, you are given 8 bits (I think) as 
a interrupt mask.  What they mean is left to the implementer.  Isn't 
that special?

So on that ONE architecture, you can't know the answer to every question 
about those bits until you know the CPU model.  Is this enough to write 
CPUkit?  If the answer is no, you have to define a mechanism to get that 
info out of libcpu/bsp and still be able to compile cpukit/.

One general thing that is almost never knowable by CPU kit is caching 
details.

>>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.

Ralf, I and others have cleaned up the other ports to have an interface 
between that CPUkit and libcpu/bsp for that port.  Those other ports are 
"multiib clean".  We generally did not bother anyone with the changes we 
made over the past few years.

Now we are looking at the biggest and ugliest port and people are 
noticing.

What you are suggesting is valid.  Once we know what MAY need to be 
known between the CPUKit and libbsp/libcpu, we can unify that and define 
the interface more cleanly.  The reality is that it will be a set of
data items and calls that are NOT needed on all ports.

But that doesn't always work.  One example is hooks at the VERY bottom 
that may architecture specific.  But that can be covered by saying 
"PowerPC CPU models must provide X."

> 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.

I won't argue with that at all.  What we are doing now is cleaning up
the existing powerpc port so that is even possible.

> 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.

That's a valid point.  There should be some guidelines in the porting 
guide and it must also be expanding to include interactions with libcpu.

> 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.

I will argue this.  no_cpu.h is intended to be a starting point for new 
ports of the code under cpukit.  It is compileable and a good starting 
point.

Whether it is worth maintaining with the low number of new ports is up 
for debate.

I can't follow how you jumped from nocpu to powerpc.h though.

> 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?

I think that's a file that was copied last week as part of the cleanup 
and the Doxygen comment wasn't updated.  Don't read too much into that 
one.  It is just left over fomr the recent moving party.

>>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.

How do you get a unified set of vector numbers for external interrupts 
for device drivers?

I think the mips port is closer to right here.  The generic vector/isr.S
code invokes a CPU/BSP specific routine to decode PICs, etc.  The 
maximum number of vectors is specified by libcpu which may be overridden 
by the BSP.

> 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?

Not really.  It is a logical next step after the PPC code is cleaned up 
and PCI API is unified.

FWIW I am going to make the x86 PCI API match that of the PPC.  This 
looks to only require a few files to be modified.

>>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.

That's where we are now.  Cleanup and moving things around.  Once they 
are in the right places, we can unify and change them.  I personally do 
not want to change 27 powerpc .S files. :)

Any help you can provide in reducing that set will help.  I just 
randomly compared the vector.S file from mbx8xx and mpc8260ads and see 
that the only real difference is in that the MSR_IR and MSR_DR bits are 
not touched in one of them.



--joel