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 AC55BC43467 for ; Thu, 8 Oct 2020 12:52:58 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4CE4A2184D for ; Thu, 8 Oct 2020 12:52:58 +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="FMkLyebM" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730112AbgJHMw6 (ORCPT ); Thu, 8 Oct 2020 08:52:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41716 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729722AbgJHMw5 (ORCPT ); Thu, 8 Oct 2020 08:52:57 -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 A9518C061755 for ; Thu, 8 Oct 2020 05:52:57 -0700 (PDT) Received: by mail-pg1-x541.google.com with SMTP id n9so4201023pgf.9 for ; Thu, 08 Oct 2020 05:52:57 -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=FMkLyebMkzMWBBJLMa9hcgd+7THovbNFFPQHfJ9IQHAdBYQGSnhIVK8lm09h8YbYnx YepV1/rJ6bTCBXJXTKf9a2rP6Glht3KXWo36JPkkW1qt8U8qkAO5U35rV8EcQeDAVUWa FjrNucUBJ2IjwZvvhbQf1QIASozntgQHKoUhDcKhoYQ0gK7T/l+wY2a5/JLgZ7e8myuK 7rdVIgmhiHCR9WIdJ1yh18Yypg/q1RoMdcY4D7l87a4uYIrnGUzZkUzi8aA1IQbtCTrA jnYCsZokp2acmiq1Jw72vmLIuYLa47Yk4UWtkT2vlXxeue1FHMXj26fG/dZXYc9eEXBY 9pXQ== 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=izHUezW0f5BVY8uHZoQg6EfFVY7u5pcKWMd814b19QW+ZQOXJ6BRHaIKiIn1H5OYfk /wTvZjUwFL7CDFvUriM5V19PrJHgtdgXZp8V3mjFjUosb+8oWbHx0vWH/bF5EdeCGL14 9VeyKMN4iZFKMUYHoUEzUINtZiSB6KZkPrNFCsO7xZ6vWlUud67RtlHhocScumWbSxUx E0Fpmiz3QxgAnTY8yQWojKezkWmhng+jqfo1SZO1nDRik1+7hXOA7fdIt02PrsJWSd6B GDUxuTkgqiNFKegbwE3zjpLWtRO17nK4HN8k/qLrhAzWcLhIMuveAcgAxIsqJXxzKJgr Q4eg== X-Gm-Message-State: AOAM531KJxIPHjgJqGYzusLpod11+HDFXPk0rAWzZMaTKMgUN66DolGu Sz4hpB+PBBU7GymDXIuKiaw= X-Google-Smtp-Source: ABdhPJxdtunYOWVkrOCw+rpGprETOwSRVEvBIcnAmlHyNtuMk1St4f7/EcLk38UtwkJ0N3yBQrLN7A== X-Received: by 2002:a63:524a:: with SMTP id s10mr7465747pgl.40.1602161576815; Thu, 08 Oct 2020 05:52:56 -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 gp8sm6834266pjb.3.2020.10.08.05.52.53 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Thu, 08 Oct 2020 05:52:56 -0700 (PDT) Date: Thu, 08 Oct 2020 21:52:51 +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