From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from perceval.ideasonboard.com (perceval.ideasonboard.com [213.167.242.64]) (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 22B2870 for ; Tue, 6 Jul 2021 18:38:56 +0000 (UTC) Received: from pendragon.ideasonboard.com (62-78-145-57.bb.dnainternet.fi [62.78.145.57]) by perceval.ideasonboard.com (Postfix) with ESMTPSA id 78002A5E; Tue, 6 Jul 2021 20:38:53 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com; s=mail; t=1625596733; bh=w8UXpSwvhF1C7XTU/B1glTXMtEIOrpjTYvtY+yehpHY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=rLIqnV8b+A17mbWt8GwoX4bfuuo7q96Lz5Y1YPOKa8dxCYedGHTmKVrCAuBU7J66w mi/SoXhaO8AROMDja2MROIsc0FPrH2BAC02qlKCfHJOrN6zi2rUyolKdNMYdZv7dpW 2VcH4QbN58YU/SZ4KJG2RgaE1eUR3g7pSIuFDK7U= Date: Tue, 6 Jul 2021 21:38:09 +0300 From: Laurent Pinchart To: Miguel Ojeda Cc: Sasha Levin , Linus Walleij , Leon Romanovsky , ksummit@lists.linux.dev Subject: Re: [TECH TOPIC] Rust for Linux Message-ID: References: Precedence: bulk X-Mailing-List: ksummit@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Hi Miguel, On Tue, Jul 06, 2021 at 08:29:21PM +0200, Miguel Ojeda wrote: > On Tue, Jul 6, 2021 at 5:43 PM Laurent Pinchart wrote: > > > > There are lots of core APIs that are used by most drivers and that are > > not subsystem-specific, so those will need to be considered too. > > Yes, but those are maintained in the "common"/shared support, e.g. > data structures, sync-related facilities, etc.; and hopefully will be > much better understood by everyone. > > > Additionally, even if there's a subsystem maintainer willing to maintain > > a Rust abstraction, it also means that someone doing tree-wide or > > subsystem-wide refactoring will need to pull the maintainer(s) in and > > make it a team project. I really don't see how that can scale, tree-wide > > changes are already very painful. > > > > I'm afraid that doesn't really match how development is done today :-) > > Lots of subsystem-wide refactoring is done by developers who are not > > subsystem maintainers. > > What I was saying is that the changes need to go through the > maintainers, which then would know Rust and the abstractions they > maintain. > > Of course, somebody wishing to do tree-wide refactoring needs to know > at least a bit of Rust to at least know how to refactor and submit the > code for the maintainers -- but that is a given. > > After all, if we are going to have Rust as a second language in the > kernel, we should try to have as many people on board as possible, at > least to some degree, within some reasonable time frame. I agree with you here, it's a honest way to look at it: adopting Rust as a second language in the kernel isn't just a technical decision with limited impact, but also a process decision that will create a requirement for most kernel developers to learn Rust. Whether that should and will happen is what we're debating, but regardless of the outcome, it's important to phrase the question correctly, with a broad view of the implications. (That being said, there are also lots of technical challenges of course) -- Regards, Laurent Pinchart