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 7725E168 for ; Tue, 6 Jul 2021 15:02:00 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id E82BA61A3E; Tue, 6 Jul 2021 15:01:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1625583720; bh=SYrJDBP6jMDAg3PVz2HnnnIVvlEgKP6386E2LiER5WQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=C2DvVOhKQE4z82UWiPXCofw+NQeTuqI237W23kZIQasFiNecxxmfo2p+ME/lXAVwn kuPdKmlISCNsAB7GyZzgoFlpdtlypxdJnd3AOkCcGsJjSWfX8SRfVxURsUfOnNqKnH FUhIETYyMLABZ19tLKvmwpe4g/u1jcIY5/8peLEJsjMiVeDzIHgxrrvxE3dnKfTrt9 VgC3RNQ835JIxN4lrugVnUQY+yYb9HxajCCwXfiyqgF4Fw/iHK8RJ/WPHB5xHgN/6S v7nKIQelPfbyehyoI7Ad5dgDKh0EtDJqZAPiXmvKnRt1HPSe8vV4bOuhnTAknRS9Jl v82ur5ooTEI4g== Date: Tue, 6 Jul 2021 11:01:58 -0400 From: Sasha Levin To: Miguel Ojeda Cc: James Bottomley , Leon Romanovsky , Linus Walleij , ksummit@lists.linux.dev Subject: Re: [TECH TOPIC] Rust for Linux Message-ID: References: <19e0f737a3e58ed32758fb4758393c197437e8de.camel@HansenPartnership.com> Precedence: bulk X-Mailing-List: ksummit@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: On Tue, Jul 06, 2021 at 04:55:56PM +0200, Miguel Ojeda wrote: >On Tue, Jul 6, 2021 at 12:20 PM James Bottomley >> 3. Less review: The lack of kernel programmers understanding rust >> hampers reviewing. Since most of our CVE type problems are usually >> programming mistakes nowadays, the lack of review could contribute to >> an increase in programming fault type bugs which aren't forbidden by >> the safer memory model. > >Yes, this is a fair point. Initially, our plan is to work with >subsystem maintainers that do want to start providing a Rust API for >their subsystem. Then they can maintain drivers using such API. > >We definitely do not want to have drivers written for a particular >subsystem if nobody is able to review (or even write) the Rust >abstractions for that particular subsystem. How do you see this working on the -stable side of things? It's hard enough to get review for C code, the amount of people who would do a second review in the context of a -stable release would be non-existant. -- Thanks, Sasha