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

[Daniel Almeida <daniel.almeida@collabora.com>]

Hi Hans! Thank you for chiming in!

There's a few things in your email that I disagree with and that I'd
like to
address.

> I think V4L2 should be written in primarily one language.

It is, in C. This series is about adding *bindings* to write *drivers*
in Rust
*for those interested*. The v4l2 core remains untouched, and I don't
think there
are any plans to introduce Rust outside of drivers in the kernel at
all, last I
heard.

> You assume that all code is running inside the kernel and needs to be
perfect.

No I do not assume that. In fact, Rust code is absolutely not
guaranteed to be
bug free and definitely not "perfect".

On the other hand, I would take Rust over C any day. Thus I am
contributing some
of the infrastructure to make this possible for me and for others.

IMHO I think you're approaching this from the wrong angle. It isn't
that Linux
*needs* Rust. It's more about providing a new and safer choice with
modern ergonomics for developers, is all.

> I would rather like more drive on that, than flowing down the Rust
stream.

These two things are not mutually exclusive :)

> Rust is cool, Java is cool, VM's are cool.

I don't see why Java and virtual machines are being brought into the
discussion
for this patchset here. And compilation times are a part of life,
sadly. Also,
can you substantiate your claim that Rust is slow?

> Engineering energy would be much more focused, if hardware vendors
could agree
more about what binary formats to use for their device protocols,

I understand, but my patchset is not to blame here. In fact, I have no
say at
all over these things.

> than changing the coding language

This simply is not what is happening here. Again this is about giving
kernel
developers another *option* of programming language, not about ditching
C.

> that now anyone can be let loose to program in the Linux kernel
without
risking any damage

Who's "anyone"? Plus the review process stays in place, so hardly any
changes to
code quality here.

> I'm glad if not everyone out there can do my job writing C-code for
device
drivers. We don't need more people to mess around there  simply.

Ok we differ strongly here. In particular, I am totally neutral to your
first
statement.

The reality is that it isn't up to anyone to say who should or
shouldn't become
a kernel developer. The resources are out there for anyone to try, and
if
maintainers take in their patches, then that's the end of the story.

-- Daniel