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
next prev 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).