This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC PATCH 00/11] Library OS support
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Isaku Yamahata <isaku dot yamahata at gmail dot com>
- Cc: <libc-alpha at sourceware dot org>, <isaku dot yamahata at intel dot com>
- Date: Mon, 16 Sep 2019 20:47:57 +0000
- Subject: Re: [RFC PATCH 00/11] Library OS support
- Ironport-sdr: v43eJk4MGHOfNOq8rBqciFvQQayIsN9rsxoanQjsy2gAI54zfkZfA2rO1RtesGXci4EQH2XFDE E1fGRiUoi7O9heHE4/mrKPOaBJt2FAOjIGf7oGcb1eNZNnRty5GNvJJlV3P2RStpKvrNrwJyhz fKqDhmKu+HGf+pbjs8WenYF7hpA0szxNySGk+iaJwc6A5upi2yxLNeCtNJXQn51/bfOXzhINCr s03uGkmNXqG1fHsmoHld+17nqy/UFmjqE2uFoSdouRHkrnJQ0xLQdGM2aFVvoTIRV1Q942rnN9 nnw=
- Ironport-sdr: bIp6jnZGKvqxFwd6sI3H5BHfXiYX1n+mdiDk67NsZOwdZweFrNrf7WHCrTb30fjbWiNSfzHC2n 2FWDW8nqVnHDMewJlTlZ5Eu+3Sp2PcFIh9DZhXJewkz3cq77COu1tArda2Zpoo0yDHk+TDlmJr Dx2/WAY4ky1vtUyx7HvAGM05f26kIdRTJ76WCKE7p6DZx+z/vzEs+Uh3QLlC/qsqHjRAjv+Hfs +ndP8Ir80SzMYe1yqhii/7BeNOi4lh/eO9q6ne60ikEr7DZc//iiAARgHvgproCChxcZsrwERY RDQ=
- References: <cover.1568219399.git.isaku.yamahata@gmail.com> <alpine.DEB.2.21.1909120003500.28563@digraph.polyomino.org.uk> <20190912011326.GA28254@private.email.ne.jp>
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
LibOS.
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
joseph@codesourcery.com