From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-3.0 required=3.0 tests=AWL,BAYES_00, DKIM_ADSP_CUSTOM_MED,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF, FORGED_GMAIL_RCVD,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=no autolearn_force=no version=3.4.2 Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 627A71F463 for ; Tue, 17 Sep 2019 17:46:56 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:to:cc:subject:message-id:references :mime-version:content-type:in-reply-to; q=dns; s=default; b=LXSp 3RbMlyQkPS8EH6HWl8W8ILkaSY9h02cfKvHJxRbWxtH6hdr66Vtz2DT024rJsLeM HG/K3M4W0EO7eQGcSotslj68C/vpCzQ++X9bMKeYSPIZe0cH0AJoABj/57SJLAqt EUtPzvBmKrWFepVKDNL4Qz5RDS4GYPfuF4IG+zg= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:to:cc:subject:message-id:references :mime-version:content-type:in-reply-to; s=default; bh=+C9PvzxXwO iV8ty+erlOB9fm8gY=; b=JN/90FhoreuacR3Dly893ktl+m54wCVaAxORItpZ0R FnQ6AgaXoPfrOEJNa0HxqCM+qUQ3NjCm2Uj3M/dV0SD7WUJZ4IDGqu/m9J0m9Nuj 4gd5hKD3ycDvLeQoFNDvUjkKkhz7x0q3G4Dh6adhUdgYBGRK/iUt6hCaK4jdTYSt M= Received: (qmail 114655 invoked by alias); 17 Sep 2019 17:46:54 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 114645 invoked by uid 89); 17 Sep 2019 17:46:53 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: mail-pg1-f196.google.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=GHotCiQNjYQ/f9HXxqqrZePWD56QawLhhbHUSAR1i5k=; b=gkt4RhefBStFmM5jDpVIxxzx4Ba5uxs4IRZuNApwokC9byk45AcplO59ibku8N3ccZ GlTWbTMFJrUNeP5ciPyT8Z0e/75GGvpg1UyJ5nMR7fa4NmZJ219hgfetJ5ZSCLrxW1/1 cq5L2UcFujKHsaUkXYZLQlRCHJyXOuDo1X5cqfNCCFZgp0UOWw5M6tLijonaz9s0WuKT er316z8nE1IhOIUL7CSpGZhE10NZthnm+zk7xAsiL04wANZpLOByQBr46BRhg9ApjrF/ O9b3DDBbEeSJEMJ3XyNrWUm0U2vqYlf2Jc6ZQuZv6tP/21omuizMgC83q8ybkQroY8W2 Wfdw== Date: Tue, 17 Sep 2019 10:46:49 -0700 From: Isaku Yamahata To: Joseph Myers Cc: Isaku Yamahata , libc-alpha@sourceware.org, isaku.yamahata@intel.com Subject: Re: [RFC PATCH 00/11] Library OS support Message-ID: <20190917174649.GA13005@private.email.ne.jp> References: <20190912011326.GA28254@private.email.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) 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 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