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 -- --- Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren GPG/PGP-Schlüssel zu. --- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering info@xxxxxxxxx -- +49-151-27565287
