This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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),
it not.

Thanks,


Thanks,
Isaku Yamahata

On Mon, Sep 16, 2019 at 08:47:57PM +0000,
Joseph Myers <joseph@codesourcery.com> 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 
> 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

-- 
Isaku Yamahata <isaku.yamahata@gmail.com>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]