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=-13.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL 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 CAF26C433ED for ; Sat, 17 Apr 2021 13:53:27 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A771461207 for ; Sat, 17 Apr 2021 13:53:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236396AbhDQNxp (ORCPT ); Sat, 17 Apr 2021 09:53:45 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39750 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230442AbhDQNxm (ORCPT ); Sat, 17 Apr 2021 09:53:42 -0400 Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 56D30C061574 for ; Sat, 17 Apr 2021 06:53:16 -0700 (PDT) Received: by mail-wm1-x32c.google.com with SMTP id i21-20020a05600c3555b029012eae2af5d4so6025968wmq.4 for ; Sat, 17 Apr 2021 06:53:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=AewrO9ydZMH8IFjVd/qYNAdik/pmPwbpo6Np+kmyKYg=; b=LprgzkCTYyqpRBvY/OpJ5/Lw+b1fQGdy7g/Enp9yXjYrwuK0MXw3kDYO+jTVo4AM2O da349ZM4/Nio1LQFnTQBh8PdKz12IvSipdyhHL8DjTeljE3RceRtXTG/6CczWnLsmf3B ulKaALHU8CRPxtrVb9hD3ogh+kuadPguT2Ej7vHO79q8vj8IOE3N9Ix0l2G6jHCvVRmi qnArsiiziY8R4KMLfWqUBkgsIndGyrf4FG4PZbXEsgR2WKzgc4LOanTwtwky7jXdIQXd 71PMY9eC/OdM8bASwiHbP/tuvDUDapptPBkCHRt0ppck0eI0xkrbnLshbeckXqg1n5LS d/xw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=AewrO9ydZMH8IFjVd/qYNAdik/pmPwbpo6Np+kmyKYg=; b=jmx2+5vVy+0e4UDBQGcVnNQM1mYhqiXZYP77I4SUJ/8aZ6T2sH8+u0aM6hyLJcN9sW 85+PCwpleakSikrMXlFSB3B1soGt4oxf/1oPFTjltk5T4hiksooN6XZXPXk2AwxX8dEi bNVCOKgMXPwEfX434CU7zkJc++wGEK3/ARYq6Twlklz03myHDuV1AHhKXaP0phM2HMTa HC8MIMALR5VeVRY7TJp1d92UW2iJbheY/VuwC0+d4iz8e36ANN6p0tAdWvd01EOj5nSF G8UeMERkdmfgCbYbDixnjFyf8jhswXfYI8lnHR8SYCyTAbFxHtxra+qWc9FR1tX0eO7r TpkQ== X-Gm-Message-State: AOAM533i9tBXSZtGRxh3ho0uwANxJntdWVrtPYp0wLejh+5wOVVUiEBv Jq9N+qyRO5Hdnxo5xdIUM+Eu X-Google-Smtp-Source: ABdhPJx6T84mDYcYChTDx6mFZZd5JbkVIL1vfaM8A6FMAjA3GZ43YPjDBzJtaAVdVRIuMA0uMvFRtQ== X-Received: by 2002:a05:600c:3594:: with SMTP id p20mr12286134wmq.173.1618667594637; Sat, 17 Apr 2021 06:53:14 -0700 (PDT) Received: from google.com ([2a00:79e0:d:209:3c1c:8462:b77e:21a4]) by smtp.gmail.com with ESMTPSA id o5sm12394021wmc.44.2021.04.17.06.53.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 17 Apr 2021 06:53:14 -0700 (PDT) Date: Sat, 17 Apr 2021 14:53:10 +0100 From: Wedson Almeida Filho To: Willy Tarreau Cc: Peter Zijlstra , ojeda@kernel.org, Linus Torvalds , Greg Kroah-Hartman , rust-for-linux@vger.kernel.org, linux-kbuild@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 00/13] [RFC] Rust support Message-ID: References: <20210414184604.23473-1-ojeda@kernel.org> <20210416161444.GA10484@1wt.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210416161444.GA10484@1wt.eu> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Apr 16, 2021 at 06:14:44PM +0200, Willy Tarreau wrote: > But will this remain syntactically readable/writable by mere humans ? I would certainly hope so. > > Note that this is > > another area where Rust offers advantages: read-only guards (in C, if you take a > > read lock, nothing prevents you from making changes to fields you should only be > > allowed to read); > > But I'm happily doing that when I know what I'm doing. What you call a > read lock usually is in fact a shared lock as opposed to an exclusive > lock (generally used for writes). For me it's perfectly valid to perform > atomic writes under a read lock instead of forcing everyone to wait by > taking a write lock. You may for example take a read lock on a structure > to make sure that a field you're accessing in it points to stable memory > that is only modified under the write lock, but the pointer itself is > atomically accessed and swapped under the read lock. Yes, this is a great example. Also easily expressible in Rust: they have this concept of interior mutability where certain types allow their contents to be modified even when shared immutably. Atomics offer such interior mutability, so the scenario you describe is fine. Rust in fact has an extra enforcement here that C doesn't: it requires interior mutability for this scenario to be allowed, so you can't do it with a plain naked type (say u64) -- you'd need to use something like an atomic64_t, where you're required to specify memory ordering when accessing them. In C we of course have atomics but the compiler never alerts us for when we need them. > > In fact, this is also an advantage of Rust. It would *force* developers to > > lock/unlock the RCU lock before they can access the protected data. > > I'm really afraid by languages which force developers to do this or that. When I say that Rust forces developers to do certain things, it's to provide the compile-time safety guarantees. Some of these requirements are imposed by our own abstractions -- we can always revisit and try to improve them. In cases when the abstractions cannot be further refined, developers always have the escape hatch of unsafety, where they're allowed to do pretty much everything as in C, but then they also give up the compile-time guarantees for those parts.