From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.5 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id EDAADC43467 for ; Thu, 8 Oct 2020 12:53:08 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 9A1252184D for ; Thu, 8 Oct 2020 12:53:08 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="esLrePzF" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730137AbgJHMxI (ORCPT ); Thu, 8 Oct 2020 08:53:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41746 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730113AbgJHMxI (ORCPT ); Thu, 8 Oct 2020 08:53:08 -0400 Received: from mail-pg1-x541.google.com (mail-pg1-x541.google.com [IPv6:2607:f8b0:4864:20::541]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 91240C061755 for ; Thu, 8 Oct 2020 05:53:06 -0700 (PDT) Received: by mail-pg1-x541.google.com with SMTP id n9so4201334pgf.9 for ; Thu, 08 Oct 2020 05:53:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:message-id:from:to:cc:subject:in-reply-to:references :user-agent:mime-version; bh=RJe9LFXNtER/IOrNMooaftE91+H07BwPeBTcEDJvIdA=; b=esLrePzFwSEQgGn8UQR33lmWA27wtJF2YeONLwN3JWzINHoUZ9mvMFANKQXrT11afd ddaWnE+U4c5onuwo3mmkR0CDeBBSxon4huQMiz946hOjxkB+ImFPUrMX+n+IYLlXL4US 21z++AbnRVIBE+OK4c6LGDLksww5FlF6w8dNJxfXmANSvnpUtmWH/8pokT0r6OKTqOZA jLu0UD3l7xu+zFLnGtNW1uF8834nQh7gxPH+naYO+SA4Vr1dOH6HWSApkw4sqfuqITGt hfV6d9MlNBJ8HHAyZdZ/jPWVl8mmuaj1OjCyuyf8p3qG4BzpHEPX9FCBbEvhPRXxFgib Tymg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:message-id:from:to:cc:subject:in-reply-to :references:user-agent:mime-version; bh=RJe9LFXNtER/IOrNMooaftE91+H07BwPeBTcEDJvIdA=; b=PJBI+pz2CNnImh5rkyLeLgiVOtDn/HsDL8Y/zbuPL92Pty4vMPz6vUCpby3oNkK0mZ 8ECBrq8sLChOKxTGZGWvJ94f5XHCpeyMjoL/FVTIs4cTfsB5xvbsg7Jq9oZG1TvSmDDa lLT2ftiMEmeO+ABssiTDrMtHYVkovVrhVroI8ixXwUlp5mdHrRJxmM3qDJoes7SHtuEg tuDd1DASPQSSjjMGCSj+Mk6uwJ6YutdCrkgYWz7HryWMCV+QIWYIxZd9BBtQECI1zbuH /ODVCGm2c5OTrBFpHmjEcBc2/HuD3ge6cSXJ+BAV4owC6K88HeVuegRbIJQ7vMb9o2an U6KQ== X-Gm-Message-State: AOAM532f0qTCPXovj6Iq+unml+3pS/hfZ8v1GhcRQrpURyVMQMwIBmMr XazV0eH6aqS9g+t3ko6UR/g= X-Google-Smtp-Source: ABdhPJzJz9kssyboQkxTLuiQX+eMv4sU1CV8A52af5IkA5ou6U2AzITJSTu+ckQDBCdwg+en3OCgzA== X-Received: by 2002:a63:e001:: with SMTP id e1mr7113866pgh.279.1602161585975; Thu, 08 Oct 2020 05:53:05 -0700 (PDT) Received: from earth-mac.local.gmail.com (219x123x138x129.ap219.ftth.ucom.ne.jp. [219.123.138.129]) by smtp.gmail.com with ESMTPSA id h9sm6784963pfc.28.2020.10.08.05.53.02 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Thu, 08 Oct 2020 05:53:05 -0700 (PDT) Date: Thu, 08 Oct 2020 21:53:00 +0900 Message-ID: From: Hajime Tazaki To: anton.ivanov@cambridgegreys.com Cc: johannes@sipsolutions.net, linux-um@lists.infradead.org, jdike@addtoit.com, richard@nod.at, tavi.purdila@gmail.com, linux-kernel-library@freelists.org, retrage01@gmail.com, linux-arch@vger.kernel.org Subject: Re: [RFC v7 18/21] um: host: add utilities functions In-Reply-To: <2f3c3a54-7d68-6dc9-a65a-37fb4599b194@cambridgegreys.com> References: <7a39c85a38658227d3daf6443babb7733d1a1ff4.1601960644.git.thehajime@gmail.com> <27868819-fbd7-9eec-0520-d2fb9b6bf4a6@cambridgegreys.com> <6d8dd929722e419894824a07792ac8c5b2659de9.camel@sipsolutions.net> <3f0aab8f38971360240e1e04bd6b90a8dcadec86.camel@sipsolutions.net> <2f3c3a54-7d68-6dc9-a65a-37fb4599b194@cambridgegreys.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Precedence: bulk List-ID: X-Mailing-List: linux-arch@vger.kernel.org On Thu, 08 Oct 2020 00:10:23 +0900, Anton Ivanov wrote: > > > On 07/10/2020 16:03, Johannes Berg wrote: > > On Wed, 2020-10-07 at 17:02 +0200, Johannes Berg wrote: > >> On Wed, 2020-10-07 at 15:53 +0100, Anton Ivanov wrote: > >>> These are actually different on different architectures. These look > >>> like the x86 values. Those variables are based on tools/um/include/lkl/asm-generic/errno.h, which is generated from include/uapi/asm-generic/errno.h, which LKL kernel eats for its values. This is the part of patch 12/21. > >>> IMHO a kernel strerror() would be the right way of dealing with this > >>> in the long term (i understand that we cannot call the platform one, > >>> because it may be different from the internal Linux errors). It will > >>> be useful in a lot of other places. > >>> > >>> If we leave it as is, we need to make this arch specific at some > >>> point. So, this particular code does not contain arch specific part I believe. # Tavi, correct me if I'm wrong. > >>>> + > >>>> +static const char * const lkl_err_strings[] = { > >>>> + "Success", > >>>> + "Operation not permitted", > >> Might be possible to more or less address this (except for arch-specific > >> errors that don't always exist) but using C99 initializers? > >> > >> [0] = "Success", > >> [EPERM] = "Operation not permitted", > >> .. > > But, on the other hand, is it needed at all? I don't think the kernel > > ever prints out the actual string ... > > I can see the use case for a library in a multi-arch environment (which IMHO is the intended use case). It saves the user the effort of digging into the build and figuring out what does this error mean today :) > > It is nice to have :) > > If we will have it, however, it should be done as you suggested - C99 or some other way where it maps correctly to actual underlying error codes as they may end up being different depending on build config. So, this is not for the error values which underlying host generates, but the ones kernel generates. And the values should be tied with uapi/asm-generic/errno.h. One possible failure that I can see is if uapi/asm-generic/errno{-base}.h are changed. In that case, yes, the way Johannes proposed would be the right way to handle. The outlook would be with the prefix and errno name (as follows). [0] = "Success", [LKL_EPERM] = "Operation not permitted", -- Hajime