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=-5.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 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 2C80FC43460 for ; Sat, 17 Apr 2021 04:24:48 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 066BA611AB for ; Sat, 17 Apr 2021 04:24:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232896AbhDQEZL (ORCPT ); Sat, 17 Apr 2021 00:25:11 -0400 Received: from wtarreau.pck.nerim.net ([62.212.114.60]:51778 "EHLO 1wt.eu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229465AbhDQEZK (ORCPT ); Sat, 17 Apr 2021 00:25:10 -0400 Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id 13H4O52o013478; Sat, 17 Apr 2021 06:24:05 +0200 Date: Sat, 17 Apr 2021 06:24:05 +0200 From: Willy Tarreau To: Miguel Ojeda Cc: Connor Kuehl , Al Viro , Linus Torvalds , Peter Zijlstra , Miguel Ojeda , Greg Kroah-Hartman , rust-for-linux@vger.kernel.org, Linux Kbuild mailing list , "open list:DOCUMENTATION" , Linux Kernel Mailing List , Alex Gaynor , Geoffrey Thomas , Finn Behrens , Adam Bratschi-Kaye , Wedson Almeida Filho , Michael Ellerman Subject: Re: [PATCH 04/13] Kbuild: Rust support Message-ID: <20210417042405.GA13432@1wt.eu> References: <20210416220416.GA11872@1wt.eu> 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) Precedence: bulk List-ID: X-Mailing-List: rust-for-linux@vger.kernel.org On Sat, Apr 17, 2021 at 01:46:35AM +0200, Miguel Ojeda wrote: > On Sat, Apr 17, 2021 at 12:04 AM Willy Tarreau wrote: > > > > But my point remains that the point of extreme care is at the interface > > with the rest of the kernel because there is a change of semantics > > there. > > > > Sure but as I said most often (due to API or ABI inheritance), both > > are already exclusive and stored as ranges. Returning 1..4095 for > > errno or a pointer including NULL for a success doesn't shock me at > > all. > > At the point of the interface we definitely need to take care of > converting properly, but for Rust-to-Rust code (i.e. the ones using > `Result` etc.), that would not be a concern. Sure. > Just to ensure I understood your concern, for instance, in this case > you mentioned: > > result.status = foo_alloc(); > if (!result.status) { > result.error = -ENOMEM; > return result; > } Yes I mentioned this when it was my understanding that the composite result returned was made both of a pointer and an error code, but Connor explained that it was in fact more of a selector and a union. > Is your concern is that the caller would mix up the `status` with the > `error`, basically bubbling up the `status` as an `int` and forgetting > about the `error`, and then someone else later understanding that > `int` as a non-error because it is non-negative? My concern was to know what field to look at to reliably detect an error from the C side after a sequence doing C -> Rust -> C when the inner C code uses NULL to mark an error and the upper C code uses NULL as a valid value and needs to look at an error code instead to rebuild a result. But if it's more: if (result.ok) return result.pointer; else return (void *)-result.error; then it shouldn't be an issue. Willy