From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 25CEF70 for ; Thu, 8 Jul 2021 16:38:16 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id 664AD61414 for ; Thu, 8 Jul 2021 16:38:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1625762295; bh=e3mguIHkolO/cnXgHODiOPYxxjRyxVbm5V0UT2QuBnM=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=m24VkzWkT/BZtOSVtFaFSHIILBlD2ew4cGRA6llGrMxTUTzfDu/bj77jb8FN3z8AC 88Hmvu4NawwGlNisCnt0/YBCazXf1+GTmS7ZngyB8VObrGMUesyMOv5sVgCbQIso46 6yZvqTg/NsapBZUj9mJ78TLrdSCJme4YP5tD4QREOXl6+HnLFYBS4jd8wJ1dubHm34 A4v+oppH2dZSpKbFJGE53kfehPD378tRY6yz3VdJKYzyhrZibLlX6pPAumV/9BcPgx sDnoySF4mKWF0uA+QLgLt04NskSC6B+T9iv9eMsJfAuo5utMvy9Lo0rMLt/afMldmf P71aII6VtuB/A== Received: by mail-ej1-f45.google.com with SMTP id he13so10688039ejc.11 for ; Thu, 08 Jul 2021 09:38:15 -0700 (PDT) X-Gm-Message-State: AOAM530oNXrqrAwu5ByBJz5+O/18O03XUUExBufBq3opiRxpKaFmRsHA 1/RZMarJy1ERH+ZjsEkHtHoDfXetUz96pceTNcGcuA== X-Google-Smtp-Source: ABdhPJz7JDHvx7Xq4HiioeoD7LO2ZpciV52yeUj/bvz+1k8j5AZ2+oIDtmyhPoNBkuVgBBA0Je5r47od9/lvC0UQvkw= X-Received: by 2002:a17:906:c34e:: with SMTP id ci14mr3842708ejb.199.1625762294019; Thu, 08 Jul 2021 09:38:14 -0700 (PDT) Precedence: bulk X-Mailing-List: ksummit@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <1f2a62c19845e4602817c2130d47bbea02d04d1d.camel@HansenPartnership.com> <20210707203827.GI18396@quack2.suse.cz> In-Reply-To: From: Andy Lutomirski Date: Thu, 8 Jul 2021 09:38:01 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [TECH TOPIC] Rust for Linux To: Greg KH Cc: Miguel Ojeda , Wedson Almeida Filho , Jan Kara , James Bottomley , Julia Lawall , Laurent Pinchart , Linus Walleij , Roland Dreier , ksummit@lists.linux.dev Content-Type: text/plain; charset="UTF-8" On Thu, Jul 8, 2021 at 7:58 AM Greg KH wrote: > > On Thu, Jul 08, 2021 at 03:55:31PM +0200, Miguel Ojeda wrote: > > On Thu, Jul 8, 2021 at 8:11 AM Greg KH wrote: > > > > > > Thanks for the detailed explainations, it seems rust can "get away" with > > > some things with regards to reference counts that the kernel can not. > > > Userspace has it easy, but note that now that rust is not in userspace, > > > dealing with multiple cpus/threads is going to be interesting for the > > > language. > > > > Regarding parallelism, userspace deals with the same problems, so I do > > not see fundamental issues coming up there. The language was designed > > with parallelism in mind and is a definite improvement over both C and > > C++ in that regard. > > Ok, great, then how would you handle the kref issue where you need an > external lock to properly handle the reference counting logic in Rust? > Why is C so "bad" here that we require a lock but Rust would not? Can you point at a specific example in the kernel tree? The lock-and-then-put model is, at the very least, unusual, and the kref docs talk about it like it's common and self-explanatory as to when it's needed. I have personally never encountered a need for this, and I'd like to know exactly what type of use case you're thinking of. > Ok, what "model" would be better? We need a "base object" that has > solid lifecycle rules. Right now we do have that, but it's just not the > easiest to use for complex objects where we have multiple objects with > different lifecycles that all interact together. The v4l example is the > best, but the input layer also has this type of issue. >