Message-ID: <8ff91d0c-624b-2704-24b0-5b7c4ca0db1e@selasky.org>
Date:   Wed, 12 Apr 2023 12:00:59 +0200
From:   Hans Petter Selasky <hps@...asky.org>
To:     Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
Cc:     Daniel Almeida <daniel.almeida@...labora.com>, wedsonaf@...il.com,
        ojeda@...nel.org, mchehab@...nel.org, hverkuil@...all.nl,
        rust-for-linux@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-media@...r.kernel.org, kernel@...labora.com
Subject: Re: [PATCH 0/6] Initial Rust V4L2 support

On 4/11/23 21:22, Miguel Ojeda wrote:
> On Tue, Apr 11, 2023 at 5:33 PM Hans Petter Selasky <hps@...asky.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

Powered by blists - more mailing lists