Re: [PATCH 0/6] Initial Rust V4L2 support

Hans Petter Selasky
2023-04-11T09:53:26Z

On 4/11/23 01:41, Miguel Ojeda wrote:
> On Mon, Apr 10, 2023 at 8:59 PM Hans Petter Selasky <hps@selasky.org> wrote:
>>
>> 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
>
> Do you mean you need to compile `rustc`? Could you please explain why?
> Could you use your distribution's, or fetch the standalone installers
> or cache your own toolchain?

Hi Miguel,

Assume you need to update both the kernel and the rust compiler at the
same time. How do you do that? In the binary download case you have two
machines. One to build rust and one to build the kernel, so it is
technically not possible?

The Rust compiler has a dependency on the kernel and the kernel has a
dependency on the Rust compiler. That just means, some kind of changes
can never happen. This is the ingredient for never ending problems. It's
like you put some rock into the system: If this ever needs to change ...

I'll give you a real-life example to emphasis this. Apple and Microsoft
has done something very bad in the file system area. They mistreat what
happens to be the Norwegian character "å" (0xE5). Norway is where I
live. Their solution is to split the "å" character into the "a"
character (0x61) and the combining ring-over character (0x30A).

There are three problems:

1) Many Unicode implementations only expect one combining ring-over
character. Either this leads directly to a stack exploit or a denial of
service, depending on the actual code: CVE-2023-25193 (ongoing).

2) The proper solution would be to deny this kind of combining
characters, also called umlauts in Germany. Only that requires both
Apple and Microsoft to change and update both their filesystem and
kernel at the same time! The "å" character (0xE5) is essential for
quickly deleting files. Or disable this feature, and rewrite the
directory table every time a file is deleted.

3) Apple and Microsoft managed to screw this up, so that you can create
files under Microsoft (exFat-disk), that don't show up under MacOS. In
iOS they show up however, but can't be copied or moved anywhere. And if
you think your files are backed up in the iCloud, think again!

The consequences can be quite serious, that you could end up being
unfairly judged by the Police in Norway, because court documents "just
got lost" they say.

Do you think Microsoft and Apple will ever change this dependency, if a
change means you need to re-format filesystems live or risk a serious
performance degradation? I have my personal doubts.

I think the problem with the "å" character I've described above, is a
forever problem created by Apple and Microsoft and IBM and who knows
what more. It's not possible to solve, without a serious cost, and
having this secret automagic trashbin for files that just a few people
use, compared to the big picture, is not an issue for them. Even a few
people going to jail for 21 years, is not an issue. Who cares, is the
impression I get from customer support at both Microsoft and Apple. And
not at least, who knows about this really!

Daniel and Miguel: By saying it is not a good thing to build systems
completely from source, both kernel and toolchain and everything that
goes with it, you basically say that permanent "dependencies" between
the compilers and the kernel will never be a problem. You are building
on a rock, and only the future knows if what you consider a rock today
is really a problem tomorrow.

In my example the unicode alphabet is a problem. So tell me: How would
you update a system, if the value of every single letter in the unicode
alphabet would change?

>
>> 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?
>
> The Rust standalone installers are 2+ orders of magnitude lighter.

For people that build stuff on their laptops it still matters. If you
have a beefy machine, it is a different case.

>
>> The definition of "bugs" may vary of course. I was thinking more like
>> stack exploits, missing validation of arrays and so on.
>
> The kernel definitely needs to avoid those. What do you mean?

I thought that Rust didn't allow you to write outside the bounds of
arrays, similarly to the old Turbo Pascal language?

>
>> I must admit I'm not a Rust guy and don't see the advantages of Rust
>> like you do.
>
> The advantages are fairly clear. The question has always been whether
> the cost is worth those benefits.

If there could be one base compiler and toolchain, I would be happy.

>
>> 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.
>
> That sounds like an orthogonal discussion.

Sure.

>
> In any case, please note that you would need to install the same Rust
> toolchain to compile them in userspace. So, if you are concerned about
> the size of the toolchain (as you mention above), it would not really
> make a difference.
>
>> Rust is slow based on my observations building Firefox from sources. The
>> Rust compiler spends a significant amount of time per source file.
>
> It is slower than compiling C, but it also provides more features, so
> it seems fair for what we are getting in exchange.

Right, so think about where that slowness may end up one day, if you
suddenly need to re-build everything from sources so to say :-)

Thanks for your input!

--HPS