Re: Accelerating Y2038 glibc fixes

[Wolfgang Denk <wd at denx dot de>]

Dear Florian,

In message <874l3mjgi6.fsf@oldenburg2.str.redhat.com> you wrote:
>
> One difficult trade-off is that for you, this is just one-time
> enablement work, but the regular contributors will be stuck with the
> code you add forever.  Especially since it touches 64-bit architectures
> as well.

I am aware of this, and I'm willing to go all necessary procedures
to get things right.  If someone points out a problem, we can
address it, and move on.  But we haven't seen any progress for a
long time...

> For me personally, the whole project is quite baffling.  I'm interested
> in 32-bit changes only to support legacy binaries, and this is new work
> targeting new binaries.

Indeed it is easy for all the big distros who dropped (at least
commercial) support for 32 bit systems years ago.  But this is only
a fraction of the systems that are affected, and it's not only x86.
There is a zillion of 32 bit ARM, Power architecture and MIPS
devices out there, with more of them being sold for many more years
to come, and many of these are used in products a) with product
lifetimes exceeding Y2038 and b) where being Y2038 clean is a
critical feature.

I think this is part of the problem - the big distros are not really
interested in this work, they see it only as a nuisance to their
business cases.  I cannot stop myself from stating that such an
approach is egotistic at best, if not ignorant, or both.

> Particularly for i386, it *will* lead to ABI
> fragmentation.  We can add dual ABI support for glibc, but for the rest
> of the system, distributions will have to pick a default (probably with
> their build flags selection), and they will make different choices.
> Some distributions will focus on backwards compatibility with legacy
> binaries, but others want to keep the i386 architecture alive for many
> more years.  I really do not want to deal with the resulting confusion,
> but it seems that I do not have any choice there.

As mentioned, it is not only about i386.  There are countless
Embedded Systems running 32 bit ARM, PPC and MIPS systems.

> Since I'm opposed to this entire project, I have largely refrained from
> reviews, except for things that looked obviously wrong to me (e.g.,
> things that definitely break compatibility with older kernels or
> existing ABIs), but even for those cases, my feedback probably wasn't
> very helpful.

I can understand your point of view, but indeed this is not helpful
here.  glibc is a central resource for the whole FOSS system, and we
are not pushing these changes for a fancy, but because a solution
is needed for a large number of affected projects and products.


We need to find a constructive way to proceed with this matter.  It
will not go away if we try to ignore it.

Thanks.


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
"Text processing has made it possible to right-justify any idea, even
one which cannot be justified on any other grounds."
                                                 -- J. Finnegan, USC.