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
