This is the mail archive of the
mailing list for the glibc project.
Re: [RFC PATCH 00/11] Library OS support
Distro folks have their opinion. Can anyone from distro jump-in?
Yes, it can be implemented in either way.
If it's not tested, it's broken. test should be done with minimum libos.
I understand that your point is,
If I go for a normal x86_64-*-linux-gnu, test in the upstream CI is a must,
a strong requirement.
On the other hand, If i go for x86_64-*-linux-libos-gnu(or whatever we call it),
On Mon, Sep 16, 2019 at 08:47:57PM +0000,
Joseph Myers <firstname.lastname@example.org> wrote:
> On Wed, 11 Sep 2019, Isaku Yamahata wrote:
> > If we have multiple versions, for example,
> > x86_64-*-linux
> > x86_64-*-linux_libosX
> > x86_64-*-linux_libosY
> > ...
> > it doesn't scale. It will cause maintenance hell.
> Multiple different LibOS host triplets would indeed be an issue. My point
> is more like this: in various uses of QEMU it's often better to use
> virtual boards and devices that don't correspond to any real hardware but
> are convenient for emulation and for guest operating systems, rather than
> to use emulation of a particular piece of real hardware. Similarly, if
> you don't constrain yourself to work with generic x86_64-*-linux-gnu
> libraries, you can make the syscall interface for LibOS into something
> that is designed to be convenient for library implementation on a wide
> range of possible host OSes, rather than being tied to all the
> peculiarities of the existing Linux kernel syscall ABI and the existing
> glibc ports. Only one such interface should be needed, not one for each
> If however you continue with something that works with x86_64-*-linux-gnu
> rather than a different triplet, aiming for generic x86_64-*-linux-gnu
> libraries to work in a LibOS environment, my other point from the Cauldron
> discussion applies: this is adding new interfaces to x86_64-*-linux-gnu
> glibc and so there should be additions to the glibc testsuite that verify,
> in a normal x86_64-*-linux-gnu glibc build, that those interfaces are
> working as desired for LibOS purposes. That probably means some kind of
> minimal LibOS loader, that passes syscalls through to the host operating
> system, should be included in the glibc testsuite - just as the
> test-in-container infrastructure can be seen as support for building and
> using a (very) minimal GNU/Linux distribution (complete with a local
> implementation of enough of /bin/sh to work for the glibc tests) for those
> tests that need to run in such a container environment.
> Joseph S. Myers
Isaku Yamahata <email@example.com>