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 DA836168 for ; Tue, 6 Jul 2021 15:03:30 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id 1B86B61C1C; Tue, 6 Jul 2021 15:03:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1625583810; bh=DALzHOyQKNHalMbDbq8XtmWtJsXOsY1c+VXbBBXdoZI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ekQTmaA66EfsTmebThw+9zMaGbpYoLcF4h1M0lHu/xed9NYpENnsxGIEwaQdV+Zbw muaQ8v6/q2nooM+m/VQJvADzpG9fnli4iz0y0XkkBSF3+pHJImgb9PT9Z0bcedxFw/ XdkNIQhOO47mP6H2QGJDtpmvOHXshYqsJCe1gS+GWYoaXnhWzjCQ8qU8lo2HywO3L+ TNkynz7PcnhF51QxGXBzh2zXILn1iR28upc0IDnQcisFltnhU8C125bRG0qZPAv/RT ryJQqrk0zvqzrRtsdcN6c2lY1+vcZjhV48QxnbX5c+vYMv6uKgSTSD8QWiZD11t9mr p9WQz42ThUL7w== Date: Tue, 6 Jul 2021 11:03:29 -0400 From: Sasha Levin To: Miguel Ojeda Cc: 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=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: On Tue, Jul 06, 2021 at 04:30:06PM +0200, Miguel Ojeda wrote: >On Tue, Jul 6, 2021 at 11:55 AM Linus Walleij wrote: >> >> AFAIU the idea is to replace an entire piece of code in C with the >> same piece in Rust, it's not like we are going to develop a second >> kernel in Rust inside the kernel in C. So both/and not either/or. >> I.e. you have to compile some pieces of the kernel written in >> Rust to even get to a working kernel. > >Let me clarify this, since it is important: no, we are not replacing C >code In fact, the Rust side is based on the C one. > >But that does not mean we are not rewriting a second kernel either -- >for instance, we have red-black trees "abstracted" in the Rust side by >reusing C's API. > >In other words, what we are doing is "abstract" the C APIs into Rust >APIs that can ensure as many invariants as possible statically, using >Rust facilities for that. Thus Rust is one more consumer of the C >APIs. Does this mean that anyone who wishes to modify these C APIs must also know Rust to fix up those abstractions too? -- Thanks, Sasha