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

[Enrico Weigelt, metux IT consult]

On 08.04.23 21:43, Hans Petter Selasky wrote:

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

Yes, of course. It's kernel code.

If you're borrowing kernel code for your userland stuff, than it's up
to you to take care of it.

There is no such thing like stable/fixed in-kernel APIs - it always has
been this way.

> But I think 
> you could just aswell implement the next USB webcam V4L2 driver in Perl 
> for that sake.

That would't be v4l anymore.

> The reason for my point of view, is that I think most of the drivers in 
> media/ should run in user-space, and not inside the kernel.

Feel free to provide fully userspace drivers for those devices, but
that's totally unrelated to kernel development (no matter whether you're
copying over kernel code into your userland project).

> The example of secure V4L2 programming is already here:
> https://github.com/hselasky/webcamd

BSD code is not in scope of the LKML.

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

Orthogonal topic.

> Rust is cool, Java is cool, VM's are cool. The only bad about 
> cool things, is that they are so slow. For many years I completely 
> avoided C++ code for the sake it is very slow to compile, compared to 
> bare C code. And when looking at how Firefox is building using Rust, I 
> am a little worried, why we need so much code in there!

Yes, compiling Rust is slow, compared to C. That's the price for
sophisticated optimizations. How often do you have to do a full
recompile ?

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

Indeed. But we (kernel folks) have no influence on that. If we could,
we'd already standardized HW interfaces for lots of things and so only
a small percentage of the drivers we currently have, while still
supporting the same number of HW (or even more). But unfortunately thats
not under our control. Therefore offtopic.

> than changing the coding language, so that now anyone can be let loose 
> to program in the Linux kernel without risking any damage.

AFAIK, this discussion isn't about changing the kernel's programming
language, but just adding language bindings, so some new drivers could
be written in that language. If this really happens and you really want
a C implementation, feel free to send patches.

> The goal for Linux driver development should be fewer drivers and not 
> more. 

Depends on specific case. We already have lots of drivers that support
wide range of devices. But it doesn't make sense having monster drivers
for entirely different devices.

> I don't want Linux to become the next Microsoft, with gigabytes 
> of drivers which are never used for anything.

Actually, we're doing a pretty good job of generalizing things that can
be generalized (if you find room for more improvements, feel free to
send patches). Nobody here seriously intents dropping the subsystem and
lib architectures in favour of monolithic monster drivers like in
Windows world.

> The webcamd daemon already is close to 6 MBytes big on amd64 on FreeBSD. 
> Inside there is support for 510 drivers (counting =y keywords), built 
> straight off Linus Torvalds:

You have ~500 drivers in one 6MB binary and blame us for writing too
much code ? Maybe you should think about modularization (which we do
have in the kernel).

And, btw, FreeBSD is completely off-topic here.

> The USB video class is great, instead of tons of GSPCA devices, then 
> yeah, we don't need to drag around so much legacy binaries, just to make 
> everyone happy. What did Apple do? Custom PCI webcam devices? Why can't 
> they just stick with virtual USB devices, and then have a dual 
> configured device, one config for their own HD codec, and one config for 
> people like me, just needing the framebuffer.

Well, they just could have an USB device layered on-top of a tiny PCI-
USB bridge. We're the wrong to blame - talk to Apple.


--mtx

--
---
Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert
werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
GPG/PGP-Schlüssel zu.
---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@xxxxxxxxx -- +49-151-27565287