rust-for-linux.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Hans Petter Selasky <hps@selasky.org>
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
Subject: Re: [PATCH 0/6] Initial Rust V4L2 support
Date: Sat, 8 Apr 2023 21:43:22 +0200	[thread overview]
Message-ID: <441a96cb-7dd1-0885-df64-933ebdb55e9e@selasky.org> (raw)
In-Reply-To: <20230406215615.122099-1-daniel.almeida@collabora.com>

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

  parent reply	other threads:[~2023-04-08 20:01 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-06 21:56 [PATCH 0/6] Initial Rust V4L2 support Daniel Almeida
2023-04-06 21:56 ` [PATCH 1/6] rust: media: add the media module Daniel Almeida
2023-04-06 21:56 ` [PATCH 2/6] rust: media: add initial videodev2.h abstractions Daniel Almeida
2023-04-06 21:56 ` [PATCH 3/6] rust: sync: introduce FfiMutex Daniel Almeida
2023-04-06 21:56 ` [PATCH 4/6] rust: media: videobuf2: add a videobuf2 abstraction Daniel Almeida
2023-04-06 21:56 ` [PATCH 5/6] rust: media: add {video|v4l2}_device_register support Daniel Almeida
2023-04-06 21:56 ` [PATCH 6/6] rust: media: add v4l2 rust sample Daniel Almeida
2023-04-08 19:06 ` [PATCH 0/6] Initial Rust V4L2 support Daniel Almeida
2023-04-08 19:43 ` Hans Petter Selasky [this message]
2023-04-09 14:10   ` Daniel Almeida
2023-04-10 18:59     ` Hans Petter Selasky
2023-04-10 23:41       ` Miguel Ojeda
2023-04-11  9:52         ` Hans Petter Selasky
2023-04-11 12:36           ` Miguel Ojeda
2023-04-11 13:15             ` Hans Petter Selasky
2023-04-11 14:19               ` Miguel Ojeda
2023-04-11 15:33                 ` Hans Petter Selasky
2023-04-11 19:22                   ` Miguel Ojeda
2023-04-12 10:00                     ` Hans Petter Selasky
2023-04-12 10:13                       ` Greg KH
2023-04-12 10:23                         ` Hans Petter Selasky
2023-04-10 23:40     ` Miguel Ojeda
2023-04-26 14:31   ` Enrico Weigelt, metux IT consult
2023-04-10 22:46 ` Deborah Brouwer
2023-04-11 14:22   ` Miguel Ojeda
2023-04-12  2:58     ` Theodore Ts'o
2023-04-12 12:21       ` Miguel Ojeda
2023-04-12 12:38       ` Morten Linderud
2023-04-12 18:44       ` Nicolas Dufresne
     [not found]       ` <aae753d6-6874-4f91-e7ba-bd6c77f07b62@metux.net>
2023-04-26 15:33         ` Miguel Ojeda
2023-04-11  7:51 ` Hans Verkuil
2023-04-11 12:02   ` Miguel Ojeda
2023-04-11 12:49     ` Willy Tarreau
2023-04-11 14:01       ` Daniel Almeida
2023-04-11 14:13       ` Miguel Ojeda
2023-04-11 16:52         ` Willy Tarreau
2023-04-11 19:27           ` Miguel Ojeda
2023-04-11 20:26             ` Willy Tarreau
2023-04-11 22:14               ` Miguel Ojeda
     [not found]                 ` <0da49a77-14d8-cb9d-e36d-985699746b6b@metux.net>
2023-04-26 16:05                   ` Miguel Ojeda
2023-04-26  0:32     ` Laurent Pinchart
     [not found]       ` <57ec90ad-8535-fa7d-d6de-d5c1d06f37d3@metux.net>
2023-04-26 13:29         ` Laurent Pinchart
2023-04-26 16:18       ` Miguel Ojeda
2023-04-26 16:35         ` Laurent Pinchart
2023-04-26 17:14           ` Daniel Almeida
2023-04-26 17:25             ` Laurent Pinchart
2023-05-01 20:10               ` Nicolas Dufresne
2023-05-01 20:17                 ` Asahi Lina
2023-05-01 20:19                   ` Nicolas Dufresne
2023-05-02 19:13                   ` Miguel Ojeda
2023-05-03 11:00                     ` Daniel Almeida
2023-04-26 19:58           ` Sakari Ailus
2023-07-05  6:40 ` Hans Verkuil

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=441a96cb-7dd1-0885-df64-933ebdb55e9e@selasky.org \
    --to=hps@selasky.org \
    --cc=daniel.almeida@collabora.com \
    --cc=hverkuil@xs4all.nl \
    --cc=kernel@collabora.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@kernel.org \
    --cc=ojeda@kernel.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=wedsonaf@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).