Hi Daniel,
On 4/9/23 16:10, Daniel Almeida wrote:
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.
I see your point, but still I think it is better to have good examples,
than to say, there is a room for everything, just come here :-)
Adding a dependency to build the Rust compiler even to build one or two
V4L2 device drivers, would mean a lot to my small hselasky/webcamd
project. It already has to fetch a copy of the Linux kernel, and now has
to bootstrap Rust from stage0 to stageN. I personally say no. It's like
XCode unfortunately. I download 100's of GBytes of upgrades to XCode,
and barely upload one millionth worth of code back to Apple. It's not
good. Software developers shouldn't have to download more stuff than
they upload?
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".
The definition of "bugs" may vary of course. I was thinking more like
stack exploits, missing validation of arrays and so on.
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.
I must admit I'm not a Rust guy and don't see the advantages of Rust
like you do.
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.
Why not move Linux-V4L2 drivers to user-space? In my opinion Rust is
much more easy to get going there than at the kernel level.
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?
Rust is slow based on my observations building Firefox from sources. The
Rust compiler spends a significant amount of time per source file.
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.
I think this option belongs in user-space and not Linux (the kernel).
More stuff should be moved there, that is my view.
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.
Maybe the word "anyone" was a bit unclear in this regard. I take that
back for now.
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.
The GPLv2 license should not be the only reason behind Linux developers
putting drivers in the kernel-space. I think moving more stuff to
user-space would benefit a greater purpose.
Summed up:
My main objection is Rust compiler support for _kernel_ V4L2 drivers. My
opinion it belongs to user-space for now and why not do something there
instead?
--HPS
