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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux