Re: future libc6-sparcv9 and libc6-sparcv9b support
On Thu, Aug 18, 2005 at 02:39:23AM -0400, David S. Miller wrote:
> > These days 2.6 kernel is getting popularity, so it's nice time to
> > support NPTL on sparc systems. But having a lot of optimized packages
> > and variants like NPTL take much longer build time + maintenance cost.
> > If we replace unpopular optimized libc6 packages with NPTL libc6 in
> > future, it's much valuable for users, I think.
> >
> > How about to drop libc6-sparcv9/sparcv9b and introduce NPTL-enabled
> > libc6 in future?
>
> You'll only get NPTL to work on sparcv9 and later anyways.
> Pure traditional sparc 32-bit NPTL is non-functioning even
> in the current glibc tree. And I doubt there is much incentive
> to write the support.
Well, there is some, as LinuxThreads has been removed from upstream glibc.
So supporting or not supporting NPTL equals to supporting or not supporting
pre-v9 CPUs at all.
Do you remember when we talked about how pre-v9 support could be done,
including fast mutex support (for mutexes NPTL uses just 0/1/2 values
of the futexes and does atomic ops on them, so sticking a ldstub lock
in the MS byte would work). The only major problem is the process shared
synchronization. That is dependent on an important decision.
Do we need sparcv[78] NPTL programs being able to use process shared
synchronization primitives with sparcv{9,64} NPTL programs, or is it
enough when just sparcv[78] programs can talk together and sparcv{9,64}
together? Here for dynamically linked programs sparcv[78] programs
mean 32-bit programs dynamically linked with a sparcv[78] compiled glibc.
If interoperation between pre-v9 and v9+ NPTL is needed, then we'd need
to slow v9+ NPTL down a little bit, if it is not, perhaps pre-v9
libpthread.a could have all atomicity stuff dependent on some is_v9
variable that would be set in the constructors depending on what CPU
it is running on.
Jakub
Reply to: