lkml.org 
[lkml]   [2023]   [Apr]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH 0/6] Initial Rust V4L2 support
From
On 4/6/23 23:56, Daniel Almeida wrote:
> Hi all, this is my first attempt at adding Rust support to the
> media subsystem.
>
>
> Please let me know your thoughts.
>

Hi Daniel,

I think V4L2 should be written in primarily one language.

At first, I think Rust for V4L2 has no benefits for media drivers,
webcams, DVB-S/T/T2, pointing tablets and so on. You assume that all
code is running inside the kernel and needs to be perfect. But I think
you could just aswell implement the next USB webcam V4L2 driver in Perl
for that sake.

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. The driver
is killed when the device is detached, and all lost memory is reclaimed,
automagically. Then there exist proper methods to lock-down all
interfaces and file handles, so that device drivers will not do any
harm, even if exploited. For example the Capsicum library, I'm using
FreeBSD.

Debugging stuff using GDB in user-space, is so much more convenient than
debugging stuff inside the kernel. And the development time is much faster.

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

I would rather like more drive on that, than flowing down the Rust
stream. 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!

Engineering energy would be much more focused, if hardware vendors could
agree more about what binary formats to use for their device protocols,
than changing the coding language, so that now anyone can be let loose
to program in the Linux kernel without risking any damage.

The goal for Linux driver development should be fewer drivers and not
more. 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. I don't want Linux to become the next Microsoft, with gigabytes
of drivers which are never used for anything.

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:

cat config | grep CONFIG | grep "=y" | wc -l
510

ls -l `which webcamd`
-r-xr-xr-x 1 root wheel 5915016 Mar 30 19:09 /usr/local/sbin/webcamd

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.

You asked for a comment and now you got one!

--HPS

\
 
 \ /
  Last update: 2023-04-08 21:51    [W:0.344 / U:0.492 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site