mbox series

[0/6] Initial Rust V4L2 support

Message ID 20230406215615.122099-1-daniel.almeida@collabora.com
Headers show
Series Initial Rust V4L2 support | expand

Message

Daniel Almeida April 6, 2023, 9:56 p.m. UTC
Hi all, this is my first attempt at adding Rust support to the
media subsystem.

It adds just enough support to write a clone of the virtio-camera
prototype written by my colleague, Dmitry Osipenko, available at [0].

Basically, there's support for video_device_register,
v4l2_device_register and for some ioctls in v4l2_ioctl_ops. There is
also some initial vb2 support, alongside some wrappers for some types
found in videodev2.h.

I wrote a sample Rust driver just to prove that this probes, and
that you get a message on dmesg whenever an ioctl is called.

As there is no actual implementation for any of the ioctls, this module
can misbehave with some programs. I can work around this in a future
submission.

Note that this is based on the rust branch, as opposed to rust-next. The
reasoning is simple: I expect this series to just kickstart some
discussion around the subject. Actual upstreaming can come up much
later, at which point I can rebase on the rust branch.

Lastly, the origins of this series trace back to a v4l2 virtIO driver I
was writing in Rust. As the project was eventually shelved for other
reasons, I picked both the virtIO and the v4l2 bindings into their own
patches which I am now in the process of submitting. This is to say that
I tested this code with said driver and CrosVM in the past, and it
worked ok.

Please let me know your thoughts.

[0]: https://gitlab.collabora.com/dmitry.osipenko/linux-kernel-rd/-/commit/055a2c322e931a8b388f864f1db81bbdfd525602

Daniel Almeida (6):
  rust: media: add the media module
  rust: media: add initial videodev2.h abstractions
  rust: sync: introduce FfiMutex
  rust: media: videobuf2: add a videobuf2 abstraction
  rust: media: add {video|v4l2}_device_register support
  rust: media: add v4l2 rust sample

 rust/bindings/bindings_helper.h        |   8 +
 rust/kernel/lib.rs                     |   2 +
 rust/kernel/media/mod.rs               |   6 +
 rust/kernel/media/v4l2/capabilities.rs |  80 ++++
 rust/kernel/media/v4l2/dev.rs          | 369 +++++++++++++++
 rust/kernel/media/v4l2/device.rs       | 115 +++++
 rust/kernel/media/v4l2/enums.rs        | 135 ++++++
 rust/kernel/media/v4l2/format.rs       | 178 ++++++++
 rust/kernel/media/v4l2/framesize.rs    | 176 +++++++
 rust/kernel/media/v4l2/inputs.rs       | 104 +++++
 rust/kernel/media/v4l2/ioctls.rs       | 608 +++++++++++++++++++++++++
 rust/kernel/media/v4l2/mmap.rs         |  81 ++++
 rust/kernel/media/v4l2/mod.rs          |  13 +
 rust/kernel/media/videobuf2/core.rs    | 552 ++++++++++++++++++++++
 rust/kernel/media/videobuf2/mod.rs     |   5 +
 rust/kernel/sync.rs                    |   1 +
 rust/kernel/sync/ffi_mutex.rs          |  70 +++
 samples/rust/Kconfig                   |  11 +
 samples/rust/Makefile                  |   1 +
 samples/rust/rust_v4l2.rs              | 403 ++++++++++++++++
 20 files changed, 2918 insertions(+)
 create mode 100644 rust/kernel/media/mod.rs
 create mode 100644 rust/kernel/media/v4l2/capabilities.rs
 create mode 100644 rust/kernel/media/v4l2/dev.rs
 create mode 100644 rust/kernel/media/v4l2/device.rs
 create mode 100644 rust/kernel/media/v4l2/enums.rs
 create mode 100644 rust/kernel/media/v4l2/format.rs
 create mode 100644 rust/kernel/media/v4l2/framesize.rs
 create mode 100644 rust/kernel/media/v4l2/inputs.rs
 create mode 100644 rust/kernel/media/v4l2/ioctls.rs
 create mode 100644 rust/kernel/media/v4l2/mmap.rs
 create mode 100644 rust/kernel/media/v4l2/mod.rs
 create mode 100644 rust/kernel/media/videobuf2/core.rs
 create mode 100644 rust/kernel/media/videobuf2/mod.rs
 create mode 100644 rust/kernel/sync/ffi_mutex.rs
 create mode 100644 samples/rust/rust_v4l2.rs

Comments

Daniel Almeida April 8, 2023, 7:06 p.m. UTC | #1
By the way, one of the things I dislike about this series is that
there's a needless distinction between

struct Foo(bindgen::foo)

vs

struct FooRef(*mut bindgen::foo)

This gets in the way of having an owned Foo embedded into a larger
struct. It also gets in the way of instantiating an owned Foo on the
stack.

My first thought was to use enums:

enum Foo {
  Owned(bindgen::foo),
  NotOwned(*mut bindgen::foo),
}

But that would mean that users would invariably pay the price for the
owned variant always, as enums use as much space as its largest
variant.

My current understanding is that we can move all the implementations to
traits, with a suitable bound on AsRef<bindings::foo> and
AsMut<bindings::foo>.

Here is a code example for the wrapper of bindings::v4l2_format (see
format.rs), which was extended to account for both owned and non-owned
bindgen types:


```
use core::cell::UnsafeCell;

/// The shared implementation between Format and FormatRef.
pub trait FormatImpl: AsRef<bindings::v4l2_format> +
AsMut<bindings::v4l2_format> {
    /// Returns the `type_` field.
    fn type_(&self) -> u32 {
        self.as_ref().type_
    }

    /// Get the field `field` for the `pix` union member.
    fn pix_field(&self) -> Result<enums::Field> {
        let fmt = self.as_ref();
        let pix = &unsafe { fmt.fmt.pix };
        enums::Field::try_from(pix.field)
    }

    /// Get the field `width` for the `pix` union member.
    fn pix_width(&self) -> u32 {
        let fmt = self.as_ref();
        let pix = &unsafe { fmt.fmt.pix };
        pix.width
    }

    /// Get the field `height` for the `pix` union member.
    fn pix_height(&self) -> u32 {
        let fmt = self.as_ref();
        let pix = &unsafe { fmt.fmt.pix };
        pix.height
    }

    /// Get the field `pixelformat` for the `pix` union member.
    fn pix_pixelformat(&self) -> u32 {
        let fmt = self.as_ref();
        let pix = &unsafe { fmt.fmt.pix };
        pix.pixelformat
    }

    /// Get the field `bytesperline` for the `pix` union member.
    fn pix_bytesperline(&self) -> u32 {
        let fmt = self.as_ref();
        let pix = &unsafe { fmt.fmt.pix };
        pix.bytesperline
    }

    /// Get the field `sizeimage` for the `pix` union member.
    fn pix_sizeimage(&self) -> u32 {
        let fmt = self.as_ref();
        let pix = &unsafe { fmt.fmt.pix };
        pix.sizeimage
    }

    /// Get the field `colorspace` for the `pix` union member.
    fn pix_colorspace(&self) -> Result<enums::Colorspace> {
        let fmt = self.as_ref();
        let pix = &unsafe { fmt.fmt.pix };
        enums::Colorspace::try_from(pix.colorspace)
    }

    /// Set the field `field` for the `pix` union member.
    fn set_pix_field(&mut self, field: enums::Field) {
        let fmt = self.as_mut();
        let pix = &mut unsafe { fmt.fmt.pix };
        pix.field = field as u32;
    }

    /// Set the field `width` for the `pix` union member.
    fn set_pix_width(&mut self, width: u32) {
        let fmt = self.as_mut();
        let pix = &mut unsafe { fmt.fmt.pix };
        pix.width = width;
    }

    /// Set the field `height` for the `pix` union member.
    fn set_pix_height(&mut self, height: u32) {
        let fmt = self.as_mut();
        let pix = &mut unsafe { fmt.fmt.pix };
        pix.height = height;
    }

    /// Set the field `pixelformat` for the `pix` union member.
    fn set_pix_pixel_format(&mut self, pixel_format: u32) {
        let fmt = self.as_mut();
        let pix = &mut unsafe { fmt.fmt.pix };
        pix.pixelformat = pixel_format;
    }

    /// Set the field `bytesperline` for the `pix` union member.
    fn set_pix_bytesperline(&mut self, bytesperline: u32) {
        let fmt = self.as_mut();
        let pix = &mut unsafe { fmt.fmt.pix };
        pix.bytesperline = bytesperline;
    }

    /// Set the field `sizeimage` for the `pix` union member.
    fn set_pix_sizeimage(&mut self, sizeimage: u32) {
        let fmt = self.as_mut();
        let pix = &mut unsafe { fmt.fmt.pix };
        pix.sizeimage = sizeimage;
    }

    /// Set the field `sizeimage` for the `pix` union member.
    fn set_pix_colorspace(&mut self, colorspace: enums::Colorspace) {
        let fmt = self.as_mut();
        let pix = &mut unsafe { fmt.fmt.pix };
        pix.colorspace = colorspace as u32;
    }
}

/// A wrapper over a pointer to `struct v4l2_format`.
#[derive(Copy, Clone, Debug, PartialEq, PartialOrd)]
pub struct FormatRef(*mut bindings::v4l2_format);

impl FormatRef {
    /// # Safety
    /// The caller must ensure that `ptr` is valid and remains valid
for the lifetime of the
    /// returned [`FormatRef`] instance.
    pub unsafe fn from_ptr(ptr: *mut bindings::v4l2_format) -> Self {
        Self(ptr)
    }
}

impl AsRef<bindings::v4l2_format> for FormatRef {
    fn as_ref(&self) -> &bindings::v4l2_format {
        // SAFETY: ptr is safe during the lifetime of [`FormatRef`] as
per
        // the safety requirement in `from_ptr()`
        unsafe { self.0.as_ref().unwrap() }
    }
}

impl AsMut<bindings::v4l2_format> for FormatRef {
    fn as_mut(&mut self) -> &mut bindings::v4l2_format {
        // SAFETY: ptr is safe during the lifetime of [`FormatRef`] as
per
        // the safety requirement in `from_ptr()`
        unsafe { self.0.as_mut().unwrap() }
    }
}

impl FormatImpl for FormatRef {}

/// An owned version of `FormatRef`.
#[derive(Default)]
pub struct Format(UnsafeCell<bindings::v4l2_format>);

impl AsRef<bindings::v4l2_format> for Format {
    fn as_ref(&self) -> &bindings::v4l2_format {
        // SAFETY:
        // It is safe to dereference the pointer since it is valid
whenever this type is instantiated.
        // It is safe to cast this into a shared reference: because
this is the
        // only method that returns &bindings::v4l2_format and because
we take
        // &self, the compiler takes care of enforcing the Rust
reference rules for
        // us. Thus, enforcing the safety guarantees of
UnsafeCell::get() by
        // proxy.
        unsafe { &*self.0.get() }
    }
}

impl AsMut<bindings::v4l2_format> for Format {
    fn as_mut(&mut self) -> &mut bindings::v4l2_format {
        // SAFETY:
        // It is safe to dereference the pointer since it is valid
whenever this type is instantiated.
        // It is safe to cast this into an exclusive reference: because
this is the
        // only method that returns &mut bindings::v4l2_format and
because we take
        // &mut self, the compiler takes care of enforcing the Rust
reference rules for
        // us. Thus, enforcing the safety guarantees of
UnsafeCell::get() by
        // proxy.
        unsafe { &mut *self.0.get() }
    }
}

impl FormatImpl for Format {}

```

This makes it possible to:

- Share the implementations between Format and FormatRef,
- Have both Format (while paying the cost of storing the
bindings::v4l2_format member) and FormatRef (while paying the cost of
storing a pointer) separately.
- Be generic over Format and FormatRef when needed, e.g.:

```
fn some_fn(format: impl FormatImpl) {...}
``` 

Thoughts?

-- Daniel
Hans Petter Selasky April 8, 2023, 7:43 p.m. UTC | #2
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
Hans Petter Selasky April 10, 2023, 6:59 p.m. UTC | #3
Hi Daniel,

On 4/9/23 16:10, Daniel Almeida wrote:
> Hi Hans! Thank you for chiming in!
> 
> There's a few things in your email that I disagree with and that I'd
> like to
> address.
> 
>> I think V4L2 should be written in primarily one language.
> 
> It is, in C. This series is about adding *bindings* to write *drivers*
> in Rust
> *for those interested*. The v4l2 core remains untouched, and I don't
> think there
> are any plans to introduce Rust outside of drivers in the kernel at
> all, last I
> heard.

I see your point, but still I think it is better to have good examples, 
than to say, there is a room for everything, just come here :-)

Adding a dependency to build the Rust compiler even to build one or two 
V4L2 device drivers, would mean a lot to my small hselasky/webcamd 
project. It already has to fetch a copy of the Linux kernel, and now has 
to bootstrap Rust from stage0 to stageN. I personally say no. It's like 
XCode unfortunately. I download 100's of GBytes of upgrades to XCode, 
and barely upload one millionth worth of code back to Apple. It's not 
good. Software developers shouldn't have to download more stuff than 
they upload?

> 
>> You assume that all code is running inside the kernel and needs to be
> perfect.
> 
> No I do not assume that. In fact, Rust code is absolutely not
> guaranteed to be
> bug free and definitely not "perfect".

The definition of "bugs" may vary of course. I was thinking more like 
stack exploits, missing validation of arrays and so on.

> On the other hand, I would take Rust over C any day. Thus I am
> contributing some
> of the infrastructure to make this possible for me and for others.
I must admit I'm not a Rust guy and don't see the advantages of Rust 
like you do.

> IMHO I think you're approaching this from the wrong angle. It isn't
> that Linux
> *needs* Rust. It's more about providing a new and safer choice with
> modern ergonomics for developers, is all.

Why not move Linux-V4L2 drivers to user-space? In my opinion Rust is 
much more easy to get going there than at the kernel level.

> 
>> I would rather like more drive on that, than flowing down the Rust
> stream.
> 
> These two things are not mutually exclusive :)
> 
>> Rust is cool, Java is cool, VM's are cool.
> 
> I don't see why Java and virtual machines are being brought into the
> discussion
> for this patchset here. And compilation times are a part of life,
> sadly. Also,
> can you substantiate your claim that Rust is slow?

Rust is slow based on my observations building Firefox from sources. The 
Rust compiler spends a significant amount of time per source file.

>> Engineering energy would be much more focused, if hardware vendors
> could agree
> more about what binary formats to use for their device protocols,
> 
> I understand, but my patchset is not to blame here. In fact, I have no
> say at
> all over these things.
> 
>> than changing the coding language
> 
> This simply is not what is happening here. Again this is about giving
> kernel
> developers another *option* of programming language, not about ditching
> C.

I think this option belongs in user-space and not Linux (the kernel). 
More stuff should be moved there, that is my view.

> 
>> that now anyone can be let loose to program in the Linux kernel
> without
> risking any damage
> 
> Who's "anyone"? Plus the review process stays in place, so hardly any
> changes to
> code quality here.

Maybe the word "anyone" was a bit unclear in this regard. I take that 
back for now.

>> 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.
> 
> Ok we differ strongly here. In particular, I am totally neutral to your
> first
> statement.
> 
> The reality is that it isn't up to anyone to say who should or
> shouldn't become
> a kernel developer. The resources are out there for anyone to try, and
> if
> maintainers take in their patches, then that's the end of the story.
The GPLv2 license should not be the only reason behind Linux developers 
putting drivers in the kernel-space. I think moving more stuff to 
user-space would benefit a greater purpose.

Summed up:

My main objection is Rust compiler support for _kernel_ V4L2 drivers. My 
opinion it belongs to user-space for now and why not do something there 
instead?

--HPS
Miguel Ojeda April 10, 2023, 11:40 p.m. UTC | #4
On Sun, Apr 9, 2023 at 4:10 PM Daniel Almeida
<daniel.almeida@collabora.com> wrote:
>
> and I don't
> think there
> are any plans to introduce Rust outside of drivers in the kernel at
> all, last I
> heard.

This was indeed our original proposal (actually, for "leaf" modules in
general, not only device drivers), but where the line is drawn is up
to the kernel maintainers. For instance, some of them have expressed
interest in potentially having Rust subsystems in the future.

Cheers,
Miguel
Miguel Ojeda April 11, 2023, 7:27 p.m. UTC | #5
On Tue, Apr 11, 2023 at 6:52 PM Willy Tarreau <w@1wt.eu> wrote:
>
> But if that code is only under a module, there's no need to turn all
> that code off if it's sufficient to be certain the module was no loaded.
> Plus it's more friendly to the user who doesn't have to rebuild a kernel,
> just blacklist a module and check that the kernel doesn't get tainted
> again.

That could apply to any foreign-to-us subsystems, including C code
too. Should we taint per subsystem so that we can easily check for
those that we may not trust?

I see one could argue for an experimental taint or making it depend on
something like `STAGING`, i.e. based on grounds of being new code. But
I don't see why that should be grounded on just being a different
language or not being able to read the code.

> It could depend on the layer where it plugs and the level of intimacy
> with the core. Sometimes you need a deep understanding of all interactions
> between elements to imagine possible scenarios.

Please note that the policy for submitting new Rust code is that the
respective kernel maintainers and their lists are contacted. We also
request that maintainers take the code through their tree if they can,
rather than going through the Rust tree, precisely so that maintainers
are aware of these potential interactions. See
https://rust-for-linux.com/contributing#the-rust-subsystem for
details.

Cheers,
Miguel
Miguel Ojeda April 11, 2023, 10:14 p.m. UTC | #6
On Tue, Apr 11, 2023 at 10:26 PM Willy Tarreau <w@1wt.eu> wrote:
>
> I don't know, maybe that would be a bit too fine. But at least a tainted
> flag is much less intrusive than forcing a user to rebuild and disable
> possibly important features that they would only be willing to disable
> for just a test.

It may be useful early on to have an easy way to check if any Rust
modules got loaded (though note that `RUST` is not tristate so far, so
you would still have something loaded). It could be extra optional
output in e.g. `lsmod`.

However, I don't know why that should imply tainting, especially
medium- and long-term -- please see below.

> have a hard time understanding that code that interacts with their
> subsystems, even if they try hard. It's exactly the same reason why
> 25 years ago Linus asked to stop abusing assembly code. If a language
> is only understood by a subset of developers, by nature it becomes
> more difficult to maintain in some areas.

Yeah, but that is why the idea was that Rust goes first into
subsystems where maintainers are willing to put some time into it now
and evaluate its merits. That way we also build more Rust expertise
across the kernel over time, so that later it is easier for others
(e.g. by having examples of API design and drivers, more people to
refer to, better tooling...).

But, yes, if Rust grows to be really successful within the kernel,
then at some point some basic understanding of Rust will be needed by
most kernel developers. I think that is fine, as long as there is
enough time to adjust.

> Sure, but as you said, "if they can". I thought that it could be both
> elegant, lightweight and convenient. But I'm not trying to sell this
> idea, just sharing it.

To be clear, it is still up to each subsystem to decide whether to
take Rust code. What I meant by "if they can" is that, if they are
willing to, then ideally the code would go through their tree too. The
exception are core APIs, where I asked for flexibility from all sides,
so that those subsystems willing to try Rust do not get completely
blocked.

Cheers,
Miguel
Theodore Ts'o April 12, 2023, 2:58 a.m. UTC | #7
On Tue, Apr 11, 2023 at 04:22:56PM +0200, Miguel Ojeda wrote:
> 
> Thanks, it is great to hear that the guide helped! :)
> 
> On resources: nowadays we have a webpage, too. Still to be completed,
> but you may find it useful already: https://rust-for-linux.com

Something that would perhaps be useful is to document (a) what
versions of Rust is available for various distributions, or pointers
to how to get that information for various distributions.  For
example, you can get that information from Debian using [1].  It
appears that Fedora isn't distributing rustc at *all*, at least
according to [2], so apparently for Fedora people will need to install
it from source.

[1] https://packages.debian.org/search?keywords=rustc&searchon=names&suite=all&section=all
[2] https://idroot.us/install-rust-fedora-37/

The other thing that would be worth documenting is (b) something about
what versions of Rust people have actually tested.  The comments at
[3] are quite scary, since per [4], the minimum version of Rustc
supported is 1.62.0 --- and per [3], **only** Rust 1.62.0 is
supported, since we use unstable Rust features.

[3] https://rust-for-linux.com/rust-version-policy
[4] https://docs.kernel.org/process/changes.html

But for example, with Debian, Debian stable is shipping Rust 1.48.0,
and Debian testing (which is currently in "hard freeze" so it can be
released as Debian stable this summer) is shipping Rustc 1.63.0.

Since I use Debian testing, the question which is foremost in my mind
is whether I can expect to have things work if I use the
distro-provided 1.63.0 rustc, or is this really a case of "it's not
Rust 1.62.0, so good luck to you"?

If the goal is accelerate adoption of Rustc, and calm people's fears
vis-a-vis using Rust, it's not enough to say, "why don't you use the
distribution-provided version or Rust"?  It would be helpful if those
Rust pioneers can share what versions of Rust they have tested
against, especially for those commonly used distributions, such as
Debian, and give us a report whether we should expect things to work,
so we can ignore the scary warning from the build system that we're
using an unsupported version of Rust, and if it breaks, we get to keep
both pieces.

And for those distributions that don't currently ship Rust, such as
Fedora, if someone could build their own unofficial packages, until we
can convince Red Hat to start shipping -their own supported Rust
compilers, that might be a great way of bridging that gap.

Cheers,

					- Ted
Hans Petter Selasky April 12, 2023, 10 a.m. UTC | #8
On 4/11/23 21:22, Miguel Ojeda wrote:
> On Tue, Apr 11, 2023 at 5:33 PM Hans Petter Selasky <hps@selasky.org> wrote:
>>
>> Similarly rustc may depend on an incorrectly specified ioctl()
>> definition, also via other libraries and static linking, that just have
>> to stay incorrectly defined, because it was initially incorrectly defined.
> 
> Why would a compiler depend on random ioctls? Even if it did, how is
> that related to the previous discussion? A compiler is just one more
> userspace application.

Hi,

Is the right hand knowing what the left hand is doing? Are the people 
behind Rust aware Rust is being used for kernel purposes or not?

That's why I brought up the file-system issue with Microsoft and Apple 
as an example. The Unicode guys probably knew nothing about what the 
letter valued 0xE5 was used for in various file systems, so they thought 
it was fine to assign a letter there, the Norwegian "å". I think neither 
anyone at the two big companies mentioned tried to stop Unicode from 
doing such a clear mistake either.

Microsoft and Apple is the left hand, and Unicode is the right hand.

That's why the toolchain should be included in the Linux kernel. So that 
the people using Linux know that the toolchain works as intended when 
compiling the Linux kernel.

It's a generic issue. If two organizations that make products for 
eachother, don't talk closely together, you risk exactly what I point 
at, that some stupid decision will be made by the one party, which 
doesn't really affect the other party, but innocent customers infact.

 > Why would a compiler depend on random ioctls?

Can you say you can write even a test C-program to multiply two 32-bit 
numbers, bit by bit, without even deleting a single character once? 
People who say C-programmers never do mistakes, are naive. Even standard 
ioctls() may contain mistakes and there needs to be a plan to fix such 
issues. And when you think the code is right, the compiler is to blame, 
and when you think the compiler is right, the CPU is to blame and so it 
goes.

> Whether the kernel uses C or Rust internally
> has nothing to do with that.

The question is not OR, but AND related. If the kernel will need both at 
some point in the future, it's not good. The plan should be either OR: 
Rustc ^ GCC = true. Not Rustc | GCC = true :-)

> Also, I don't follow your logic. You said you cannot upgrade your
> toolchain (for some reason), and your argument is that the kernel
> keeps interfaces stable? Well, yes, that is the point and what allows
> you to upgrade.

You need to see, stable interfaces may also need to be changed. That is 
where you invert my logic. If you fix that when reading my text, you 
will see what I'm saying is true and not false.

There may be bit-pattern things down at CPU level, triggering bit-flips, 
that CPU vendors will do nothing about, because the argument is 
typically about money and performance. If something costs both money and 
hurts performance, it will not be implemented. It's like the speculative 
instruction prediction and resulting cache pollution, allowing memory to 
leak from kernel level to user-space level. Isn't it enough to deal with 
this in GCC only? Does Rust handle such issues at all? I don't know simply.

And what about syscall numbers? What if someone from Intel says all 
syscall numbers must be divisible by four, because those two lower 
bit-lines are frequently subject to bit flips and we can do nothing 
about it.

> 
> Moreover, what is special about `rustc` here? What about your C toolchain?

I don't know Rustc that well, so I cannot answer what's special about 
it. But based on my existing experience with C toolchains, I don't 
expect it to be any easier, with regards to handling unforeseen issues.

> 
>> I'm trying to explain something difficult. And I'm OK that you neither
>> understand nor agree about my viewpoint. See my replies above.
> 
> No, it is not a matter of being difficult. It is just that you have
> not shown how you would be prevented from upgrading a toolchain.

The proof is in a principle. Principles are there to avoid unpredictable 
problems.

Apparently you don't accept the principle of talking closely together 
when you are in a supply chain.

I have a feeling you think like this: If I do my job great, and all 
others in the supply chain do their best, then the resulting product 
will be the great too!

Translated to your case: Linux is the most stable OS in the world, and 
Rust is the most secure compiler language in the world. Nothing can go 
wrong!

--HPS

> 
> Cheers,
> Miguel
Greg KH April 12, 2023, 10:13 a.m. UTC | #9
On Wed, Apr 12, 2023 at 12:00:59PM +0200, Hans Petter Selasky wrote:
> That's why the toolchain should be included in the Linux kernel. So that the
> people using Linux know that the toolchain works as intended when compiling
> the Linux kernel.

That's not how Linux has ever worked, sorry.  So this is not even a
valid discussion anymore.

greg k-h
Hans Petter Selasky April 12, 2023, 10:23 a.m. UTC | #10
On 4/12/23 12:13, Greg KH wrote:
> On Wed, Apr 12, 2023 at 12:00:59PM +0200, Hans Petter Selasky wrote:
>> That's why the toolchain should be included in the Linux kernel. So that the
>> people using Linux know that the toolchain works as intended when compiling
>> the Linux kernel.
> 
> That's not how Linux has ever worked, sorry.  So this is not even a
> valid discussion anymore.
> 

Well, maybe it's time to change your views on that and stop being a rock 
thrower on your friends, the compiler folks, whenever something goes wrong:

https://news.ycombinator.com/item?id=8089321

--HPS
Miguel Ojeda April 12, 2023, 12:21 p.m. UTC | #11
On Wed, Apr 12, 2023 at 4:58 AM Theodore Ts'o <tytso@mit.edu> wrote:
>
> Something that would perhaps be useful is to document (a) what
> versions of Rust is available for various distributions, or pointers
> to how to get that information for various distributions.  For
> example, you can get that information from Debian using [1].  It
> appears that Fedora isn't distributing rustc at *all*, at least
> according to [2], so apparently for Fedora people will need to install
> it from source.

As far as I understand, Fedora is actually one of the distributions
that provide a very up-to-date Rust toolchain (the latest) and can be
installed via `dnf` [1][2].

Cc'ing Josh Stone who maintains the toolchain in Fedora, just in case
there is something I am missing that the webpage may be referring to.

[1] https://packages.fedoraproject.org/pkgs/rust/rust/
[2] https://developer.fedoraproject.org/tech/languages/rust/rust-installation.html

> The other thing that would be worth documenting is (b) something about
> what versions of Rust people have actually tested.  The comments at
> [3] are quite scary, since per [4], the minimum version of Rustc
> supported is 1.62.0 --- and per [3], **only** Rust 1.62.0 is
> supported, since we use unstable Rust features.

The one that we test, for the moment, is the minimum one (since it is
the "only" one) -- I will make it more clear in the webpage.

> But for example, with Debian, Debian stable is shipping Rust 1.48.0,
> and Debian testing (which is currently in "hard freeze" so it can be
> released as Debian stable this summer) is shipping Rustc 1.63.0.
>
> Since I use Debian testing, the question which is foremost in my mind
> is whether I can expect to have things work if I use the
> distro-provided 1.63.0 rustc, or is this really a case of "it's not
> Rust 1.62.0, so good luck to you"?

Distro versions should be fine (as in: it is not an issue of "official
prebuilt images" vs. "distro binaries"). But short-term you likely
need to match the numbered version (or perform small changes in the
kernel side when needed). So, in practice, the easiest route is to use
the binaries provided by Rust itself (via `rustup` or standalone
installers). We could also provide them at kernel.org like for other
toolchains if that helps.

So if distributions want to start using Rust code in their kernels
right now (i.e. before we can declare a proper minimum) with their own
`rustc` package, then one approach they can use is to provide an extra
`rustc-kernel` package matching the version required by the kernel (or
to change the kernel side a bit to make it compile).

We could, in principle, attempt to support several versions in the
kernel side, but given the upstreaming of the first Rust modules is
still going on (and the abstractions they depend on), we still have
some time. Moreover, the first Rust modules may not be needed by most
distributions: what is being upstreamed is the Android Binder driver,
the Asahi GPU driver and the NVMe driver so far.

So it is up to distributions to decide whether they need to use one of
those modules early on, and if that is the case and they need to do so
before we can declare a minimum, then I think it is reasonable to ask
them to match the version. Some particular users, e.g. Android, as far
as I understand, they are OK with matching the version for the time
being.

In summary, the issue is that the minimum version we will eventually
support is "in the future".

> If the goal is accelerate adoption of Rustc, and calm people's fears
> vis-a-vis using Rust, it's not enough to say, "why don't you use the
> distribution-provided version or Rust"?  It would be helpful if those
> Rust pioneers can share what versions of Rust they have tested
> against, especially for those commonly used distributions, such as
> Debian, and give us a report whether we should expect things to work,
> so we can ignore the scary warning from the build system that we're
> using an unsupported version of Rust, and if it breaks, we get to keep
> both pieces.

Definitely -- we should be testing distro-versions in CI as soon as it
is (reasonably) possible. We could even do so already for those
distributions that track the latest version, but then it means we will
be upgrading more often (every 6 weeks) in the kernel side. There
would still be small windows where it may not work depending on how
the schedules match, though (but distros could keep a `rustc-old` for
some days until it matches again, for instance).

> Fedora, if someone could build their own unofficial packages, until we
> can convince Red Hat to start shipping -their own supported Rust
> compilers, that might be a great way of bridging that gap.

I think all major distributions already ship Rust. From a quick look:
Fedora (1.68.2), Gentoo (1.68.2), Arch (1.68.2), openSUSE (1.68.0 for
the rolling one), Ubuntu (1.67.1 for 23.04), Debian (1.63.0 this
summer), Red Hat (1.62.1 in 9.1)...

As mentioned above, if kernel maintainers are happy with more frequent
upgrades (i.e. tracking the latest release), it would at least be
easier for those in distributions that track the latest Rust release
-- I would like to do that, in fact, if nobody opposes, since our idea
is to anyhow upgrade the compiler required in the kernel until we hit
the minimum.

What do you think?

Cheers,
Miguel
Morten Linderud April 12, 2023, 12:38 p.m. UTC | #12
On Tue, Apr 11, 2023 at 10:58:34PM -0400, Theodore Ts'o wrote:
> On Tue, Apr 11, 2023 at 04:22:56PM +0200, Miguel Ojeda wrote:
> > 
> > Thanks, it is great to hear that the guide helped! :)
> > 
> > On resources: nowadays we have a webpage, too. Still to be completed,
> > but you may find it useful already: https://rust-for-linux.com
> 
> Something that would perhaps be useful is to document (a) what
> versions of Rust is available for various distributions, or pointers
> to how to get that information for various distributions.  For
> example, you can get that information from Debian using [1].  It
> appears that Fedora isn't distributing rustc at *all*, at least
> according to [2], so apparently for Fedora people will need to install
> it from source.

You can get a list here:
https://repology.org/project/rust/versions

Another alternative is this webpage:
https://pkgs.org/download/rust
Nicolas Dufresne April 12, 2023, 6:44 p.m. UTC | #13
Hi Theodore,

Le mardi 11 avril 2023 à 22:58 -0400, Theodore Ts'o a écrit :
> And for those distributions that don't currently ship Rust, such as
> Fedora, if someone could build their own unofficial packages, until we
> can convince Red Hat to start shipping -their own supported Rust
> compilers, that might be a great way of bridging that gap.

Rust can be installed from package on Fedora. I sense a lot of unverified
supposition to justify your argument. I don't believe this contribute much to
the discussion. It takes about 30s to search on your preferred search engine and
find the fact the Fedora ships rustc, and the version is very recent.

regards,
Nicolas
Laurent Pinchart April 26, 2023, 12:32 a.m. UTC | #14
On Tue, Apr 11, 2023 at 02:02:17PM +0200, Miguel Ojeda wrote:
> On Tue, Apr 11, 2023 at 9:51 AM Hans Verkuil <hverkuil@xs4all.nl> wrote:
> >
> > One of my main concerns here is time: as subsystem maintainers we can barely
> > keep up with all the incoming patches. Introducing support for a new language
> > would add only more pressure. Even though these are mainly bindings (as I
> > understand it), this would still require that every change to a C kAPI is
> > duplicated in rust, requiring someone to do that work, and have maintainers
> > with enough rust knowledge to verify it.

Another issue is that the V4L2 subsystem is plagued with lifetime
management problems. I don't think rust bindings could be safely written
for the MC and V4L2 subdev in-kernel APIs at the moment for instance.
Sakari recently attempted to fix some of those issues (again), see [1].
Progress is slow on this front because V4L2 is generally understaffed.

[1] https://lore.kernel.org//20230201214535.347075-1-sakari.ailus@linux.intel.com

Now, I hope that mentioning "lifetime management problems" will be
enough to nerd-snipe a rust enthusiast or two to help fix the C code in
order to implement proper rust bindings on top ;-)

> Indeed, that is one of the main costs.
> 
> One potential solution is to have somebody step up as the maintainer
> of the Rust side (e.g. the author of the abstractions).

That would certainly be a required step, but I don't think it would be
enough. On good days I see the media subsystem as barely able to cope
with the current load, on bad days it feels it's completely collapsing.

We have homework to do when it comes to maintenance for the media
subsystem, we're doing *really* badly at the moment regarding community
management and attracting (and retaining) new core contributors. This is
a topic I really want to discuss face to face during the media workshop
in Prague (and I know that many people are looking forward to that
discussion).

> Of course, that will not make the work go to zero, since there still
> needs to be some degree of communication even if the new maintainer
> does all the Rust side work, but it may make it feasible, especially
> if the abstracted parts of the C API do not change too frequently.
> 
> It is also an opportunity for existing maintainers to see how the Rust
> side would work meanwhile the work gets done, and potentially a chance
> to get a new maintainer involved with the whole subsystem in the
> future.
> 
> Some subsystems may want to give that maintainer a different
> `MAINTAINERS` entry, e.g. as a child subsystem that sends PRs to the
> main one and may be marked as "experimental". This is also a way to
> see how the new abstractions work or not, giving maintainers more time
> to decide whether to commit to a Rust side or not.
> 
> I don't mean to say it would be doable for the media subsystem, but
> please consider it.
Laurent Pinchart April 26, 2023, 1:29 p.m. UTC | #15
On Wed, Apr 26, 2023 at 03:13:10PM +0200, Enrico Weigelt, metux IT consult wrote:
> On 26.04.23 02:32, Laurent Pinchart wrote:
> 
> > We have homework to do when it comes to maintenance for the media
> > subsystem, we're doing *really* badly at the moment regarding community
> > management and attracting (and retaining) new core contributors. 
> 
> Is this a problem of the subsys (core) itself or individual drivers ?

It's first and foremost a subsystem core issue. Drivers will also have
to be fixed, but the core needs to be handled first.
Enrico Weigelt, metux IT consult April 26, 2023, 2:31 p.m. UTC | #16
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
Miguel Ojeda April 26, 2023, 3:33 p.m. UTC | #17
On Wed, Apr 26, 2023 at 3:37 PM Enrico Weigelt, metux IT consult
<lkml@metux.net> wrote:
>
> As already said in my other mail, one major problem IMHO is (recent
> enough) toolchain availability for the major distros and package build
> systems - including the embedded ones (ptxdist, buildroot, bitbake,
> ...).
>
> IMHO, those who want Rust in the kernel, should take care of this first.
> (and no: asking to download some precompiled binary from somewhere is
> not any acceptable solution)

Some distributions already provide up-to-date Rust versions compiled
by themselves. Those should work if we start tracking the latest
version, which is what I discussed above.

You can, of course, do it yourself too and build the compiler
yourself. Other that that, if you are not OK with third-party
binaries, or binaries we could potentially upload to kernel.org, there
is little we can do until the minimum version arrives to your favorite
distribution.

Having said that, we still need to declare a minimum version, and for
that, extra funding or engineer-hours would be helpful. If your
organization/company is up for it, please contact me.

> ACK. Maybe those folks could set up some CIs for at least building and
> deploying the Rust patches on as many distros as possible - hopefully
> before they're sent to lkml.

I am unsure what you are asking for. Testing patches for the Rust
subsystem? We already do that, of course, and some independent CIs and
companies have already started building with Rust some configs (e.g.
KernelCI and 0-Day).

If you are concerned about distributions breaking their toolchains,
well, sure, we could also test their packages. But it would be best
that, instead, distributions looking to support kernel developers set
up a test on their side, since they are the ones deciding what to do
with their toolchain packages.

I talked with a few distributions' maintainers about this lately, and
most of them were very helpful, so they may be interested in
supporting kernel developers using their distribution for development.
Would that help?

Cheers,
Miguel
Miguel Ojeda April 26, 2023, 4:05 p.m. UTC | #18
On Wed, Apr 26, 2023 at 3:36 PM Enrico Weigelt, metux IT consult
<info@metux.net> wrote:
>
> The tricky question is: how much time will be needed ?

That depends on how fast Rust grows in the kernel itself, so I would
expect it will be a self-regulating feedback loop.

> Personally, I'm too overloaded for diving deeper into Rust anytime soon.

That is fine, one can always wait a bit more to see how things evolve.

Now, if somebody wants to use Rust in a subsystem you maintain, then
you can always consider letting them maintain that part. As I
mentioned above, that can be a quite nice approach to learn Rust on
the side and recruit new future maintainers/reviewers.

> Rust and golang share some common problems (when coming from traditional
> C + friends):
> * entirely different toolchain concept (workflows are very different
>    from what one's used from GCC + friends)

I am not sure what you mean, but `rustc` uses LLVM for codegen, and
`rustc_codegen_gcc` and GCC Rust are coming.

If you mean on the developer UX side, for the kernel at least, you
still call `make` as usual. Of course, some things differ here and
there, and there are still things to improve, but it is fairly usable
even at this stage.

We are also working on introducing some features that the C side does
not have yet. So there can be upsides on this regard, too.

> * fast-moving target (one has to be careful to expect/use the right
>    toolchain version)

This currently applies to the kernel, yes, because we require some
unstable features.

To be clear, this is something that we are working on solving,
precisely because we know it is not ideal. In any case, the decision
made was to go forward meanwhile that got solved, and it is not a
blocker for some users/companies.

> * rarely understood by traditional kernel devs

Not sure what you mean by this, but a few traditional kernel devs have
successfully picked up Rust already and are interested in increasing
their usage of it.

> * distro/build engine integration/support still pretty infant,

Most distros package Rust as explained above, which may be enough for
you depending on the distro you use.

> IMHO, before we can practically use Rust at greater scale in the kernel,
> the problems above need to be resolved first. And that's something that

That depends on the user/company/entity. For instance, some companies
and projects already want to use (or are using) Rust in the kernel,
because they control their toolchains.

> And beware: demanding newer toolchains (thus newer distros), just for
> building the kernel, can easily cause *huge* trouble many organisations,
> especially in embedded field. Linux is used in lots of highly safety
> critical environments that need special verification processes and so
> cannot easily upgrade toolchains. If Linux some day suddenly requires
> another language like Rust, those would be immediately cut-off from
> newer releases.

That is fine -- many companies and projects have different
requirements, and nobody expects everybody to enable Rust in their
kernel nor to make it a hard/unconditional requirement anytime soon
(if it ever happens).

> Ergo: the whole process of adding Rust to the Kernel needs to be done
> very, very carefully.

Indeed -- if you have particular concerns that you think have not been
addressed yet in the last 2+ years, please contact us.

> For the reasons above, the subsystems shouldn't take those decisions
> lightly, even if they happen to be Rust experts - this could have a
> dramatic effect on downstreams.

There is no effect on downstream, unless they drop support for what
they already have. But that is just like any other proposed removal.

> Maybe we should (for certain time) go a different path: move all new
> Rust stuff (except for bugfixes) to a separate downstream tree, that's
> rebased on mainline releases, but still let the patches fload through
> the corresponding subsystems.

That would not accomplish anything except making everything more
opaque, not to mention harder for downstream users who are waiting for
things to land.

Again, if you have particular concerns, please feel free to raise
them, but please note that most of this has been discussed for a long
time and decided upon.

Cheers,
Miguel
Miguel Ojeda April 26, 2023, 4:18 p.m. UTC | #19
On Wed, Apr 26, 2023 at 2:32 AM Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
>
> Now, I hope that mentioning "lifetime management problems" will be
> enough to nerd-snipe a rust enthusiast or two to help fix the C code in
> order to implement proper rust bindings on top ;-)

Good idea ;)

I think it is definitely a good opportunity to consider how Rust could
fit the new design, and perhaps borrow some ideas from Rust for the
new design, even. If you feel like a quick meeting could help on that,
please let us know.

> That would certainly be a required step, but I don't think it would be
> enough. On good days I see the media subsystem as barely able to cope
> with the current load, on bad days it feels it's completely collapsing.
>
> We have homework to do when it comes to maintenance for the media
> subsystem, we're doing *really* badly at the moment regarding community
> management and attracting (and retaining) new core contributors. This is
> a topic I really want to discuss face to face during the media workshop
> in Prague (and I know that many people are looking forward to that
> discussion).

I am sorry to hear that. One idea would be offsetting the extra work
by having the Rust person also take care of some of the C parts too.
That way you can also potentially get them to be a full maintainer at
some point, even if the Rust experiment does not pan out.

Of course, easier said than done, and managing more people always
takes extra time, but getting more people seems to be part of the
solution anyway, from what you say.

In any case, thanks a lot for at least considering it :)

Cheers,
Miguel
Laurent Pinchart April 26, 2023, 4:35 p.m. UTC | #20
Hi Miguel,

(CC'ing Sakari Ailus)

On Wed, Apr 26, 2023 at 06:18:35PM +0200, Miguel Ojeda wrote:
> On Wed, Apr 26, 2023 at 2:32 AM Laurent Pinchart wrote:
> >
> > Now, I hope that mentioning "lifetime management problems" will be
> > enough to nerd-snipe a rust enthusiast or two to help fix the C code in
> > order to implement proper rust bindings on top ;-)
> 
> Good idea ;)
> 
> I think it is definitely a good opportunity to consider how Rust could
> fit the new design, and perhaps borrow some ideas from Rust for the
> new design, even. If you feel like a quick meeting could help on that,
> please let us know.

I think we have a fairly good view of what needs to be done, the rules
are the same regardless of the programming language and whether the
compiler or reviewers enforce them (Hans, Sakari, please feel free to
disagree). Thanks for your offer though, it's appreciated.

> > That would certainly be a required step, but I don't think it would be
> > enough. On good days I see the media subsystem as barely able to cope
> > with the current load, on bad days it feels it's completely collapsing.
> >
> > We have homework to do when it comes to maintenance for the media
> > subsystem, we're doing *really* badly at the moment regarding community
> > management and attracting (and retaining) new core contributors. This is
> > a topic I really want to discuss face to face during the media workshop
> > in Prague (and I know that many people are looking forward to that
> > discussion).
> 
> I am sorry to hear that. One idea would be offsetting the extra work
> by having the Rust person also take care of some of the C parts too.
> That way you can also potentially get them to be a full maintainer at
> some point, even if the Rust experiment does not pan out.

That's certainly something I would consider very positive. If anyone is
interested in having a look at (part of) the problem and possible
solutions, [1] is the most recent patch series posted to handle some of
the lifetime issues, and [2] is a more generic version of part of [1].

[1] https://lore.kernel.org/linux-media/20230201214535.347075-1-sakari.ailus@linux.intel.com/
[2] https://lore.kernel.org/linux-kernel/161117153248.2853729.2452425259045172318.stgit@dwillia2-desk3.amr.corp.intel.com/

> Of course, easier said than done, and managing more people always
> takes extra time, but getting more people seems to be part of the
> solution anyway, from what you say.
> 
> In any case, thanks a lot for at least considering it :)
Daniel Almeida April 26, 2023, 5:14 p.m. UTC | #21
Hi,

As I said higher up on this thread, I can maintain the Rust bits and 
help out with the issues around it.

IMHO, we should at least try this. Who knows, it might work out :)

Laurent, maybe we can take a piecemeal approach? Right now there are no 
bindings for MC, but I wouldn't complain about fixing some of the C code 
when the time comes.

Just FYI, I am writing some more bindings, just enough to write a 
stateless decoder driver. I hope to finish it in time for the media 
summit. It will give us a more in-depth idea of the pros and cons here.

-- Daniel
Laurent Pinchart April 26, 2023, 5:25 p.m. UTC | #22
Hi Daniel,

On Wed, Apr 26, 2023 at 06:14:33PM +0100, Daniel Almeida wrote:
> Hi,
> 
> As I said higher up on this thread, I can maintain the Rust bits and 
> help out with the issues around it.
> 
> IMHO, we should at least try this. Who knows, it might work out :)
> 
> Laurent, maybe we can take a piecemeal approach? Right now there are no 
> bindings for MC, but I wouldn't complain about fixing some of the C code 
> when the time comes.

The lifetime issues affect plain V4L2 video nodes too I'm afraid :-)

> Just FYI, I am writing some more bindings, just enough to write a 
> stateless decoder driver. I hope to finish it in time for the media 
> summit. It will give us a more in-depth idea of the pros and cons here.
Sakari Ailus April 26, 2023, 7:58 p.m. UTC | #23
Hi Laurent, Miguel,

On Wed, Apr 26, 2023 at 07:35:12PM +0300, Laurent Pinchart wrote:
> Hi Miguel,
> 
> (CC'ing Sakari Ailus)

Thanks for cc'ing me.

> 
> On Wed, Apr 26, 2023 at 06:18:35PM +0200, Miguel Ojeda wrote:
> > On Wed, Apr 26, 2023 at 2:32 AM Laurent Pinchart wrote:
> > >
> > > Now, I hope that mentioning "lifetime management problems" will be
> > > enough to nerd-snipe a rust enthusiast or two to help fix the C code in
> > > order to implement proper rust bindings on top ;-)
> > 
> > Good idea ;)
> > 
> > I think it is definitely a good opportunity to consider how Rust could
> > fit the new design, and perhaps borrow some ideas from Rust for the
> > new design, even. If you feel like a quick meeting could help on that,
> > please let us know.
> 
> I think we have a fairly good view of what needs to be done, the rules
> are the same regardless of the programming language and whether the
> compiler or reviewers enforce them (Hans, Sakari, please feel free to
> disagree). Thanks for your offer though, it's appreciated.

I guess on many you don't need to care about lifetime management if you can
assume that certain things never go away. Sometimes these assumptions prove
incorrect, and that's what's happened here.

> 
> > > That would certainly be a required step, but I don't think it would be
> > > enough. On good days I see the media subsystem as barely able to cope
> > > with the current load, on bad days it feels it's completely collapsing.
> > >
> > > We have homework to do when it comes to maintenance for the media
> > > subsystem, we're doing *really* badly at the moment regarding community
> > > management and attracting (and retaining) new core contributors. This is
> > > a topic I really want to discuss face to face during the media workshop
> > > in Prague (and I know that many people are looking forward to that
> > > discussion).
> > 
> > I am sorry to hear that. One idea would be offsetting the extra work
> > by having the Rust person also take care of some of the C parts too.
> > That way you can also potentially get them to be a full maintainer at
> > some point, even if the Rust experiment does not pan out.
> 
> That's certainly something I would consider very positive. If anyone is
> interested in having a look at (part of) the problem and possible
> solutions, [1] is the most recent patch series posted to handle some of
> the lifetime issues, and [2] is a more generic version of part of [1].
> 
> [1] https://lore.kernel.org/linux-media/20230201214535.347075-1-sakari.ailus@linux.intel.com/
> [2] https://lore.kernel.org/linux-kernel/161117153248.2853729.2452425259045172318.stgit@dwillia2-desk3.amr.corp.intel.com/

Thanks for the pointer, this would be nice indeed.

I haven't had time to work on the media device referencing series, overall
it should be good for merging but Hans found an issue I haven't had time to
debug yet. I do intend to continue that in the near future though.
Nicolas Dufresne May 1, 2023, 8:10 p.m. UTC | #24
Le mercredi 26 avril 2023 à 20:25 +0300, Laurent Pinchart a écrit :
> Hi Daniel,
> 
> On Wed, Apr 26, 2023 at 06:14:33PM +0100, Daniel Almeida wrote:
> > Hi,
> > 
> > As I said higher up on this thread, I can maintain the Rust bits and 
> > help out with the issues around it.
> > 
> > IMHO, we should at least try this. Who knows, it might work out :)
> > 
> > Laurent, maybe we can take a piecemeal approach? Right now there are no 
> > bindings for MC, but I wouldn't complain about fixing some of the C code 
> > when the time comes.
> 
> The lifetime issues affect plain V4L2 video nodes too I'm afraid :-)

Everything under the bindings is unsafe code, so it does not prevent doing upper
implementation and have other things be memory safe. It just make Rust less
helpful in some cases (I guess everything across ops).

There is low hanging fruit if some folks are interested. I see legitimate
benefit in rewriting in rust the JPEG parser, the H.264 reference list
generator, and maybe VP9 probability update lib. AV1 driver will need a lib to
reduce duplicates, this could be done straight in Rust (offering a C interface
of course, so it does not matter if the users are written in rust or C).

Nicolas

> 
> > Just FYI, I am writing some more bindings, just enough to write a 
> > stateless decoder driver. I hope to finish it in time for the media 
> > summit. It will give us a more in-depth idea of the pros and cons here.
> 
> -- 
> Regards,
> 
> Laurent Pinchart
>
Asahi Lina May 1, 2023, 8:17 p.m. UTC | #25
On 02/05/2023 05.10, Nicolas Dufresne wrote:
> Le mercredi 26 avril 2023 à 20:25 +0300, Laurent Pinchart a écrit :
>> Hi Daniel,
>>
>> On Wed, Apr 26, 2023 at 06:14:33PM +0100, Daniel Almeida wrote:
>>> Hi,
>>>
>>> As I said higher up on this thread, I can maintain the Rust bits and
>>> help out with the issues around it.
>>>
>>> IMHO, we should at least try this. Who knows, it might work out :)
>>>
>>> Laurent, maybe we can take a piecemeal approach? Right now there are no
>>> bindings for MC, but I wouldn't complain about fixing some of the C code
>>> when the time comes.
>>
>> The lifetime issues affect plain V4L2 video nodes too I'm afraid :-)
> 
> Everything under the bindings is unsafe code, so it does not prevent doing upper
> implementation and have other things be memory safe. It just make Rust less
> helpful in some cases (I guess everything across ops).
> 
> There is low hanging fruit if some folks are interested. I see legitimate
> benefit in rewriting in rust the JPEG parser, the H.264 reference list
> generator, and maybe VP9 probability update lib. AV1 driver will need a lib to
> reduce duplicates, this could be done straight in Rust (offering a C interface
> of course, so it does not matter if the users are written in rust or C).

Unfortunately I don't think actually replacing the C implementations 
will be possible until Rust architecture support is on par with C, which 
probably means waiting until gccrs is ready...

We could have both implementations until then (and only use the C one 
where Rust doesn't work), but the code duplication has an extra 
maintenance cost so it's not free. That's why people are mostly focusing 
on drivers first instead of core code.

~~ Lina
Nicolas Dufresne May 1, 2023, 8:19 p.m. UTC | #26
Le mardi 02 mai 2023 à 05:17 +0900, Asahi Lina a écrit :
> On 02/05/2023 05.10, Nicolas Dufresne wrote:
> > Le mercredi 26 avril 2023 à 20:25 +0300, Laurent Pinchart a écrit :
> > > Hi Daniel,
> > > 
> > > On Wed, Apr 26, 2023 at 06:14:33PM +0100, Daniel Almeida wrote:
> > > > Hi,
> > > > 
> > > > As I said higher up on this thread, I can maintain the Rust bits and
> > > > help out with the issues around it.
> > > > 
> > > > IMHO, we should at least try this. Who knows, it might work out :)
> > > > 
> > > > Laurent, maybe we can take a piecemeal approach? Right now there are no
> > > > bindings for MC, but I wouldn't complain about fixing some of the C code
> > > > when the time comes.
> > > 
> > > The lifetime issues affect plain V4L2 video nodes too I'm afraid :-)
> > 
> > Everything under the bindings is unsafe code, so it does not prevent doing upper
> > implementation and have other things be memory safe. It just make Rust less
> > helpful in some cases (I guess everything across ops).
> > 
> > There is low hanging fruit if some folks are interested. I see legitimate
> > benefit in rewriting in rust the JPEG parser, the H.264 reference list
> > generator, and maybe VP9 probability update lib. AV1 driver will need a lib to
> > reduce duplicates, this could be done straight in Rust (offering a C interface
> > of course, so it does not matter if the users are written in rust or C).
> 
> Unfortunately I don't think actually replacing the C implementations 
> will be possible until Rust architecture support is on par with C, which 
> probably means waiting until gccrs is ready...
> 
> We could have both implementations until then (and only use the C one 
> where Rust doesn't work), but the code duplication has an extra 
> maintenance cost so it's not free. That's why people are mostly focusing 
> on drivers first instead of core code.

Didn't know that, let's postpone this idea then.

thanks,
Nicolas

> 
> ~~ Lina
> 
>
Miguel Ojeda May 2, 2023, 7:13 p.m. UTC | #27
On Mon, May 1, 2023 at 10:17 PM Asahi Lina <lina@asahilina.net> wrote:
>
> Unfortunately I don't think actually replacing the C implementations
> will be possible until Rust architecture support is on par with C, which
> probably means waiting until gccrs is ready...

There is also a second approach via `rustc_codegen_gcc`: Antoni (Cc'd)
showed in Kangrejos and LPC last year that it could compile the Rust
kernel code (with a few tweaks).

Cheers,
Miguel
Daniel Almeida May 3, 2023, 11 a.m. UTC | #28
Hi Lina, all,

I disagree that we need to wait for anything as a precondition for
writing the things Nicolas listed. The reason being that he listed out
some very self-contained codebases. These would not depend on the
kernel crate either for the most part (or at all, even, but going from
memory here..).

Note that the codec library in particular would rarely be touched after
it's written, as the algorithms in there are more or less "set in
stone" by the codec specs.

Maintaining these until they can be merged would be essentially free,
unless I am missing something?


-- Daniel