ppc multlibs and BSP removal was Re: powerpc altivec support

[Sergei Organov]

Ralf Corsepius <ralf.corsepius at rtems.org> writes:
> On Wed, 2005-02-09 at 18:00 +0300, Sergei Organov wrote:
> > "Joel Sherrill <joel at OARcorp.com>" <joel.sherrill at OARcorp.com> writes:
> > [...]
> > > I think old exception process is now done to 4xx and a few 6xx BSPs. I
> > > know of one old exception 6xx BSP which is in use and needs to be
> > > updated. They have offered to do the conversion but that project has
> > > been up to its eyeballs the past 6 months and has barely made
> > > deadlines close enough to keep managment happy on required tasks. If
> > > someone can mechanically update it to the new exception model, I will
> > > be happy to merge that and kill the 6xx BSPs. I might even be willing
> > > to consider killing all the old exception 6xx BSPs except that and
> > > quit building it for a while.
> > 
> > Well, I use old exception processing for my own MPC509, MPC56x, and
> > MPC8270 BSPs. I don't in fact care about multilib variants provided
> > old exception processing support code remains in the source tree.
> Let me put that clear:
> 
> It's my goal to eliminate one of the exception processing variants
> inside of the source-tree, but I don't actually care which one, because
> the powerpc port in RTEMS is a maintenance nightmare.

So the right solution is to eliminate both ;) I mean it, really.

Actually current powerpc port in RTEMS just misses the cpukit entirely,
-- almost everything is BSP-dependent, so any attempt to apply
cpukit-mulitilib idiom to this port will end up in a mess of huge amount
of variants, as you in fact end up building bspkit-multilib.

> As Joel and other clearly seem to favor the "new exception processing
> model",

IMHO, "old exception processing" is not very good w.r.t. to cpukit
separation, but the "new exception processing" is yet another step in
wrong direction, I believe, and it has in fact nothing to do with the
way exceptions are handled.

> I think the "old exception processing model" is condemned to die
> sooner or later ...

Well, even then I can keep it in my own CVS repository so please feel
free not to care about my preferences.

> > In general, I consider multilib support in RTEMS to be too much overhead
> > for an end-user that probably has to deal with 1-2 processor variants
> > total. For example, I use single-lib gcc for all the above processor
> > variants, and 3 BSPs total.
>
> Well, nothing prevents you from doing this, but "times-are-a-changing".
>
> I expect us to start shipping binary cpukits for rtems-4.7, so end
> users will not have to rebuild them.

Well, disk space is cheap nowadays, but unfortunately shipping binaries
doesn't reduce overall system complexity and maintenance costs.

> Also it is not unlikely we will have to enforce multilibs in future
> (Not any time soon, but I won't exclude it).

I don't think that will be a problem for me. What I actually do is: I
build multilib gcc with only 2 variants (2 because I didn't find a way
to have 1 variant and still be "multilib"). This way, whatever RTEMS way
is, I'll end up with maximum 2 variants of RTEMS cpukits, as far as I
can tell.

-- 
Sergei.