Glibc, large PIDs etc (Was: Killing clones)

Alexander L. Belikoff (abel@bfr.co.il)
20 Aug 1997 12:07:50 +0300

> >
> > In general this brings up the question of whether we want to enforce a
> > requirement that people upgrade to glibc when we move forward to the 2.2
> > kernel.....
>
> It might not be a terribly good idea to break all of the commercial software
> built against libc 5. Linux's reputation for binary compatibility is already
> shabby enough.
>
> Could we use a separate personailty for this type of thing? Seems like it
> would be easy enough to implement a proper 32bit syscall convention and
> provide a kernel-level thunk down to 16bit values where necessary?
>
>

Isn't it easier to retain a binary compatibility for some period of
time with *both* having glibc around? Nobody argues that we'll move to
glibc ultimately, so the commercial software developers will have to
support it. Hopefully it's gonna be the last substantial libc change.

BTW, Some of the commercial ISVs may find glibc very attractive, since
the threads support in it is better than in libc. Let alone the
locale.

So anyway, why don't make the same thing people made for moving to
ELF? I guess RedHat is a perfect candidate to start it... ;-) (just a
hint, no pun intended)

-- 
-Alexander


==============================================================================
Alexander L. Belikoff			abel@bfr.co.il
Berger Financial Research Ltd.
=============================================================================