cpukit/bspkit split.

[Sergei Organov]

Ralf Corsepius <ralf.corsepius at rtems.org> writes:
> On Tue, 2005-02-22 at 18:04 +0300, Sergei Organov wrote:
> > Ralf Corsepius <ralf.corsepius at rtems.org> writes:
> > 
> 
> > They are naturally different. I think we have 3 alternatives to manage
> > it: 
> > 
> > 1. Try to manage differences at link/run time instead of compile-time.
> > 2. Move exception management out of cpukit into libcpu.
> > 3. Manage differences through different multilib variants.
> > 
> > My own preference currently seems to b (2).
> > 
> > > 
> > > > The interrupt vector numbers are more or less PIC dependant, 
> > > > although they might be shared between boards with the same 
> > > > integrated chips like MPC860 or MPC8260. So they should be 
> > > > located somewhere in a bsp/shared directory (how about something 
> > > > like: lib/libbsp/powerpc/shared/mpc860/include/mpc860.h)
> > >
> > > I disagree - you are shifting around problems. IMO, libcpu would be the
> > > appropriate location.
> > 
> > Now I tend to disagree in turn. What Thomas suggests is more natural
> > place. Ask yourself a question: where would I put the code if the PIC is
> > not integrated? The answer is: in libbsp. Right?
>
> Not necessarily. Implementing it under libbsp is just one possibility.

Too bad. It means RTEMS doesn't currently have obvious place to put IC
code into.

> 
> However, where is its API defined?

Good question.

> If either you implement a BSP specific API, then the BSP's headers is
> the appropriate place, or you implement a cpu-family API. In this
> case, a libcpu header is the appropriate location.

I believe I implement neither. I implement (non-existing) RTEMS
interrupt API as applied to the particular IC. It has in fact little to
do with particular CPU. Just imagine the day after tomorrow Motorola
releases new MPC micro-controller that consists of mpc565 core and
mpc8260 PIC. As for BSP, particular BSP should just select an
appropriate IC code from those that are available. If there is no
support for the IC the board contains, the BSP designer should implement
the IC support in appropriate place in advance and then use it in the
BSP.

> 
> > Overall, my currently preferred suggestion is:
> > 
> > 1. Have exception management code in libcpu/shared.
> > 2. Have interrupt management code in libbsp/shared.
>
> I am strongly opposed to implement anything below libbsp/shared or
> libbsp/<cpu>/shared (I guess this is what you actually mean), because it
> helps people to avoid thinking on APIs. Have a look at the currently
> existing BSPs and how they use "<cpu>/shared".

Well, the contents of c/src/lib/libbsp/shared seems OK to me. What's a
problem about it? Where do you think this code belongs?
c/src/lib/libcpu/shared?

c/src/lib/libbsp/powerpc/shared... Hmm... The only somewhat relevant are
'start' and 'vectors' directories, but they well could be in
c/src/libcpu/powerpc/shared instead, I think. I have absolutely no idea
how to "share" (I mean reuse) the rest of contents of this, -- it all
seems to be too dependent on particular CPU/board combination(s) to be
reusable. Well, on the other hand people do need a place where to put
code that is indeed shared between two or more supported BSPs.

Once again the above discussion shows that there is no clear
understanding about how the code should be actually split between
libraries and source directories. Everybody has his own opinion that has
logical arguments behind it. It's too bad as it means developers will
tend to put new code rather randomly depending on their own preferences
and understanding.

-- 
Sergei.