All of lore.kernel.org
 help / color / mirror / Atom feed
From: Willy Tarreau <w@1wt.eu>
To: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Cc: Hans Verkuil <hverkuil@xs4all.nl>,
	Daniel Almeida <daniel.almeida@collabora.com>,
	wedsonaf@gmail.com, ojeda@kernel.org, mchehab@kernel.org,
	rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-media@vger.kernel.org, kernel@collabora.com
Subject: Re: [PATCH 0/6] Initial Rust V4L2 support
Date: Tue, 11 Apr 2023 18:52:44 +0200	[thread overview]
Message-ID: <ZDWQXDRknzFhngyk@1wt.eu> (raw)
In-Reply-To: <CANiq72n8ZV_bs_xp5rNtar4vmfknJtZg4OHJW6vHuhVFmGs8mg@mail.gmail.com>

On Tue, Apr 11, 2023 at 04:13:36PM +0200, Miguel Ojeda wrote:
> On Tue, Apr 11, 2023 at 2:49 PM Willy Tarreau <w@1wt.eu> wrote:
> >
> > This might sound strange, but I suspect that having a TAINT_RUST flag
> > could possibly help maintainers that are already lacking time, because
> > it may quickly allow some of them to ask "please try again without the
> > Rust code to see if the problem is still there", just like happens with
> > out-of-tree code for which the knowledge is limited to null. This could
> > allow to route issue reports to one maintainer when an issue is confirmed
> > in both cases or to another one when it only happens in a single case.
> >
> > Of course it will not help with code reviews but we know that a great
> > part of maintainers' time it spent trying to analyse problem reports
> > that happen under vague conditions. All the time not spent debugging
> > something not well understood is more time available for reviews.
> 
> You can already ask to disable `CONFIG_RUST`.
> 
> In fact, we asked that a few times, when people reported a problem
> that looked unrelated to Rust, to confirm that was the case and thus
> redirect the report.
> 
> So it is definitely a good idea to ask for that when you get a report
> with `RUST=y` and you suspect it may be related to that, especially in
> the beginning where `RUST=y` should not be common.

But if that code is only under a module, there's no need to turn all
that code off if it's sufficient to be certain the module was no loaded.
Plus it's more friendly to the user who doesn't have to rebuild a kernel,
just blacklist a module and check that the kernel doesn't get tainted
again.

> However, I think Rust in-tree code is different to out-of-tree code,
> since you do have the code, and thus (in general) you should be able
> to reproduce the build, and you can ask for help to the given
> maintainers to understand it.

It could depend on the layer where it plugs and the level of intimacy
with the core. Sometimes you need a deep understanding of all interactions
between elements to imagine possible scenarios.

Cheers,
Willy

  reply	other threads:[~2023-04-11 16:52 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-06 21:56 [PATCH 0/6] Initial Rust V4L2 support Daniel Almeida
2023-04-06 21:56 ` [PATCH 1/6] rust: media: add the media module Daniel Almeida
2023-04-06 21:56 ` [PATCH 2/6] rust: media: add initial videodev2.h abstractions Daniel Almeida
2023-04-06 21:56 ` [PATCH 3/6] rust: sync: introduce FfiMutex Daniel Almeida
2023-04-06 21:56 ` [PATCH 4/6] rust: media: videobuf2: add a videobuf2 abstraction Daniel Almeida
2023-04-06 21:56 ` [PATCH 5/6] rust: media: add {video|v4l2}_device_register support Daniel Almeida
2023-04-06 21:56 ` [PATCH 6/6] rust: media: add v4l2 rust sample Daniel Almeida
2023-04-08 19:06 ` [PATCH 0/6] Initial Rust V4L2 support Daniel Almeida
2023-04-08 19:43 ` Hans Petter Selasky
2023-04-09 14:10   ` Daniel Almeida
2023-04-10 18:59     ` Hans Petter Selasky
2023-04-10 23:41       ` Miguel Ojeda
2023-04-11  9:52         ` Hans Petter Selasky
2023-04-11 12:36           ` Miguel Ojeda
2023-04-11 13:15             ` Hans Petter Selasky
2023-04-11 14:19               ` Miguel Ojeda
2023-04-11 15:33                 ` Hans Petter Selasky
2023-04-11 19:22                   ` Miguel Ojeda
2023-04-12 10:00                     ` Hans Petter Selasky
2023-04-12 10:13                       ` Greg KH
2023-04-12 10:23                         ` Hans Petter Selasky
2023-04-10 23:40     ` Miguel Ojeda
2023-04-26 14:31   ` Enrico Weigelt, metux IT consult
2023-04-10 22:46 ` Deborah Brouwer
2023-04-11 14:22   ` Miguel Ojeda
2023-04-12  2:58     ` Theodore Ts'o
2023-04-12 12:21       ` Miguel Ojeda
2023-04-12 12:38       ` Morten Linderud
2023-04-12 18:44       ` Nicolas Dufresne
     [not found]       ` <aae753d6-6874-4f91-e7ba-bd6c77f07b62@metux.net>
2023-04-26 15:33         ` Miguel Ojeda
2023-04-11  7:51 ` Hans Verkuil
2023-04-11 12:02   ` Miguel Ojeda
2023-04-11 12:49     ` Willy Tarreau
2023-04-11 14:01       ` Daniel Almeida
2023-04-11 14:13       ` Miguel Ojeda
2023-04-11 16:52         ` Willy Tarreau [this message]
2023-04-11 19:27           ` Miguel Ojeda
2023-04-11 20:26             ` Willy Tarreau
2023-04-11 22:14               ` Miguel Ojeda
     [not found]                 ` <0da49a77-14d8-cb9d-e36d-985699746b6b@metux.net>
2023-04-26 16:05                   ` Miguel Ojeda
2023-04-26  0:32     ` Laurent Pinchart
     [not found]       ` <57ec90ad-8535-fa7d-d6de-d5c1d06f37d3@metux.net>
2023-04-26 13:29         ` Laurent Pinchart
2023-04-26 16:18       ` Miguel Ojeda
2023-04-26 16:35         ` Laurent Pinchart
2023-04-26 17:14           ` Daniel Almeida
2023-04-26 17:25             ` Laurent Pinchart
2023-05-01 20:10               ` Nicolas Dufresne
2023-05-01 20:17                 ` Asahi Lina
2023-05-01 20:19                   ` Nicolas Dufresne
2023-05-02 19:13                   ` Miguel Ojeda
2023-05-03 11:00                     ` Daniel Almeida
2023-04-26 19:58           ` Sakari Ailus
2023-07-05  6:40 ` Hans Verkuil

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=ZDWQXDRknzFhngyk@1wt.eu \
    --to=w@1wt.eu \
    --cc=daniel.almeida@collabora.com \
    --cc=hverkuil@xs4all.nl \
    --cc=kernel@collabora.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@kernel.org \
    --cc=miguel.ojeda.sandonis@gmail.com \
    --cc=ojeda@kernel.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=wedsonaf@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.