Re: SF Bay area hackfest

On Tue, 23 Mar 2004, Daniel Eischen wrote:
>
> For the KSE bits, we've already said a few times that we're
> ready to go but are waiting for a toolchain upgrade that
> supports TLS.
>
> > going to enforce.  I don't want 5.3 to go out with hap-hazard and/or
> > unfinished TLS support.  SO let me start the list, and I'll let you and
> > others add to it.  If we can't get through this step, then there is
> > absolutely no way that we can expect to get this done for 5.3.  And for
> > the record, I would really, really like to see this done for 5.3.
>
> I don't quite understand why you need commitments for a toolchain
> upgrade.  From what I understand, TLS support can't happen without
> it, and by deferring the toolchain update you prevent it from
> getting done.  But I'll play along regardless...

Operating without a plan or commitments leads us back to 2002 with KSE.
If TLS needs a new binutils, then we need to figure out who is going to
provide that.  If no one is going to provide it, then the rest is futile,
no?

>
> >  Task                                 Owner
> >
> >  Import new GCC                       Alexander Kavaev
> >  Import new binutils                  ???
> >  Modify loader (image activator?)
> >   to understand TLS                   ???
> >  Modify KSE to understand TLS         ???
>
> Yes, I'm sure I and/or David can support this.
>
> >  Modify THR to understand TLS         ???
> >  Modify C_R to understand TLS         ???
>
> Death to C_R, death to C_R, ...
>

What happens when the compiler, toolchain, etc, etc, are all updated to
make TLS work, but the user libmaps C_R in?  Does stuff blow up?  I'm ok
with C_R not explicitely supporting it so long as it doesn't create new
failure cases.

Maybe this task list can be appended to Marcel's page and then linked
somewhere prominently.  If not then I'll create a new project page for
it.

Scott