Re: [PATCH 0/6] Initial Rust V4L2 support

[Willy Tarreau <w@1wt.eu>]

On Tue, Apr 11, 2023 at 09:27:35PM +0200, Miguel Ojeda wrote:
> On Tue, Apr 11, 2023 at 6:52 PM Willy Tarreau <w@1wt.eu> wrote:
> >
> > 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.
> 
> That could apply to any foreign-to-us subsystems, including C code
> too. Should we taint per subsystem so that we can easily check for
> those that we may not trust?

I don't know, maybe that would be a bit too fine. But at least a tainted
flag is much less intrusive than forcing a user to rebuild and disable
possibly important features that they would only be willing to disable
for just a test.

> I see one could argue for an experimental taint or making it depend on
> something like `STAGING`, i.e. based on grounds of being new code.

It could also be an idea.

> But
> I don't see why that should be grounded on just being a different
> language or not being able to read the code.

Because being a different language means some maintainers will always
have a hard time understanding that code that interacts with their
subsystems, even if they try hard. It's exactly the same reason why
25 years ago Linus asked to stop abusing assembly code. If a language
is only understood by a subset of developers, by nature it becomes
more difficult to maintain in some areas.

> > 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.
> 
> Please note that the policy for submitting new Rust code is that the
> respective kernel maintainers and their lists are contacted. We also
> request that maintainers take the code through their tree if they can,
> rather than going through the Rust tree, precisely so that maintainers
> are aware of these potential interactions. See
> https://rust-for-linux.com/contributing#the-rust-subsystem for
> details.

Sure, but as you said, "if they can". I thought that it could be both
elegant, lightweight and convenient. But I'm not trying to sell this
idea, just sharing it.

Cheers,
Willy