ksummit.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Mauro Carvalho Chehab <mchehab@kernel.org>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Jens Axboe <axboe@kernel.dk>,
	Christoph Hellwig <hch@infradead.org>,
	Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>,
	ksummit@lists.linux.dev,
	ksummit <ksummit-discuss@lists.linuxfoundation.org>
Subject: Re: [Ksummit-discuss] [TECH TOPIC] Rust
Date: Sat, 25 Jun 2022 10:15:06 -0400	[thread overview]
Message-ID: <79e0113a7eef81f2490e5531919fc4658a71c81a.camel@HansenPartnership.com> (raw)
In-Reply-To: <20220625124522.507a5b06@sal.lan>

On Sat, 2022-06-25 at 12:45 +0100, Mauro Carvalho Chehab wrote:
[...]
> Assuming that we get into a point were all the above happens for
> subsystem XXX, at the Rust experiment validation point you mentioned
> above, there will be some possible outcomes:
> 
> 1) Rust experiment fails. On such case, the efforts to make the
> subsystem C code ready to run safe Rust code will be welcomed,
> as Linux should be safer. The work on providing Rust bindings will 
> be wasted on such case. 

Not entirely ... we'll still have gone through the learning exercise of
how do you do this.  If another language promising additional safety
features comes along we'll be better at it next time.

> I can't measure how much would be spent on making C code safer and 
> how much would be on writing Rust bindings though. If such efforts 
> would be 80%-90% for making subsystems code safer, it should 
> worth the efforts even if Rust code ends being removed.
> 
> 2) Rust experiment succeeds. In long term it would mean that
> subsystems should, at some point, stop accepting C code and start
> using only Rust for new code, and several drivers in C would require
> conversion to Rust or moved to staging in order to be deprecated.

I don't think that's what success looks like.  I think we'd continue in
dual C/Rust mode almost indefinitely.  Look how long it took the kernel
to add enough flexibility just to compile the existing C with clang.

There may be a point where we ask should we deprecate C, but that's
independent of and probably way beyond the point where Rust is a
success.

> 3) Some maintainers would consider it a success while others would
> consider it a failure. That's the worse case scenario. If we reach
> that, some Kernel/Maintainers Summit hard discussions would likely 
> be needed, in order to avoid subsystem's fragmentation with regards 
> to accepting or not C and/or Rust code subsystem-wide.

So this is where we have to ask hard questions about what does success
(or failure) actually look like. I think success is really at least one
subsystem demonstrates support and enthusiasm for the Rust conversion
and it doesn't cause a huge drain on those who don't embrace it.  That
leaves open the door for more converts but doesn't force them.  We can
continually evaluate the maintenance burden in this mode and debate
whether it's too great or is acceptable.  I think failure is definitely
no subsystem wants to embrace rust.  The problem case is where a
subsystem embraces rust has issues but doesn't want to admit failure
because it would lead to the failure of the rust project ... this one
we'll need to examine in detail.

James



  reply	other threads:[~2022-06-25 14:15 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-18 20:33 Miguel Ojeda
2022-06-18 20:42 ` Laurent Pinchart
2022-06-18 20:42   ` [Ksummit-discuss] " Laurent Pinchart
2022-06-18 20:44   ` Laurent Pinchart
2022-06-18 20:44     ` [Ksummit-discuss] " Laurent Pinchart
2022-06-18 20:49   ` Miguel Ojeda
2022-06-19  6:13   ` Christoph Hellwig
2022-06-19  6:13     ` [Ksummit-discuss] " Christoph Hellwig
2022-06-19 10:04     ` Laurent Pinchart
2022-06-19 10:04       ` [Ksummit-discuss] " Laurent Pinchart
2022-06-19 12:56       ` James Bottomley
2022-06-19 12:56         ` [Ksummit-discuss] " James Bottomley
2022-06-19 13:19         ` Jens Axboe
2022-06-19 13:19           ` [Ksummit-discuss] " Jens Axboe
2022-06-19 13:53           ` Laurent Pinchart
2022-06-19 13:53             ` [Ksummit-discuss] " Laurent Pinchart
2022-06-19 14:27             ` James Bottomley
2022-06-19 14:27               ` [Ksummit-discuss] " James Bottomley
2022-06-19 14:45               ` [MAINTAINER SUMMIT] Are we becoming too fearful? [was Re: [TECH TOPIC] Rust] James Bottomley
2022-06-19 14:45                 ` [Ksummit-discuss] " James Bottomley
2022-06-22  9:59                 ` Linus Walleij
2022-06-22 10:57                   ` Laurent Pinchart
2022-06-22 12:01                     ` Linus Walleij
2022-06-22 12:09                       ` Laurent Pinchart
2022-06-22 23:13                 ` NeilBrown
2022-06-23 11:37                   ` James Bottomley
2022-06-25 12:03                 ` [Ksummit-discuss] " Mauro Carvalho Chehab
2022-06-25 11:45               ` [Ksummit-discuss] [TECH TOPIC] Rust Mauro Carvalho Chehab
2022-06-25 14:15                 ` James Bottomley [this message]
2022-06-25 16:18                   ` Mauro Carvalho Chehab
2022-06-25 22:29                 ` Linus Walleij
2022-06-26  2:52                   ` Theodore Ts'o
2022-06-26  3:18                     ` Al Viro
2022-06-19 13:49         ` Laurent Pinchart
2022-06-19 13:49           ` [Ksummit-discuss] " Laurent Pinchart
2022-06-19 19:08           ` Geert Uytterhoeven
2022-06-19 19:08             ` [Ksummit-discuss] " Geert Uytterhoeven
2022-06-19 20:57             ` Matthew Wilcox
2022-06-20 13:53             ` Linus Walleij
2022-06-20 14:08             ` James Bottomley
2022-06-21 15:11           ` Dan Carpenter
2022-06-23 10:58             ` [TECH TOPIC] Why is devm_kzalloc() harmful and what can we do about it Laurent Pinchart
2022-06-23 11:24               ` Dan Carpenter
2022-06-23 11:31                 ` Laurent Pinchart
2022-06-21  9:49 ` [TECH TOPIC] Rust David Woodhouse

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=79e0113a7eef81f2490e5531919fc4658a71c81a.camel@HansenPartnership.com \
    --to=james.bottomley@hansenpartnership.com \
    --cc=axboe@kernel.dk \
    --cc=hch@infradead.org \
    --cc=ksummit-discuss@lists.linuxfoundation.org \
    --cc=ksummit@lists.linux.dev \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=mchehab@kernel.org \
    --cc=miguel.ojeda.sandonis@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox