Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <441a96cb-7dd1-0885-df64-933ebdb55e9e@selasky.org>
Date:   Sat, 8 Apr 2023 21:43:22 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101
 Thunderbird/102.9.1
Subject: Re: [PATCH 0/6] Initial Rust V4L2 support
To:     Daniel Almeida <daniel.almeida@collabora.com>, wedsonaf@gmail.com,
        ojeda@kernel.org, mchehab@kernel.org, hverkuil@xs4all.nl
Cc:     rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org,
        linux-media@vger.kernel.org, kernel@collabora.com
References: <20230406215615.122099-1-daniel.almeida@collabora.com>
Content-Language: en-US
From:   Hans Petter Selasky <hps@selasky.org>
In-Reply-To: <20230406215615.122099-1-daniel.almeida@collabora.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

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