Conversation
liw@toot.liw.fi

Lars Wirzenius

Before thinking of how to implement some software, think hard of what it should do. "What" comes before "how". Even before that comes "why": why is the software needed?

0
0
1
jarkko

Jarkko Sakkinen

Reply to
@jani @liw even tho i work in low-level i do mostly think what users care of. as a user i don't care if there was boreboot written in BASIC, if it improved my life somehow :-) less compatible fork of coreboot does not really improve my life quality...
1
0
1
jarkko

Jarkko Sakkinen

Reply to @jarkko
I do like Rust but I do not like this "Let's reinvent the wheel... in Rust!"-culture ;-)
0
0
3
ljs

Reply to
@jani @jarkko isn't this what's happened every single time a programming language has become cool though?

Maybe I'm older than you guys but I've seen 'X written in Y' stuff all over programmer forums since... forever, where Y has varied over time to whatever the 'new language that will save us all' is with evangelical brigades telling you that if you don't use Y you're a terrible person, an antique, a monster etc.

ruby, python, d, go, clojure, ocaml, scala, kotlin, delphi, VB, js w/node, typescript, scummvm, oberon, q, actionscript and now rust!

Plus ca change!
1
0
0
jarkko

Jarkko Sakkinen

Reply to @ljs
Edited 1 year ago
@ljs @jani I'd look for places where de-facto stuff is crap or unuseful for modern use. This is why I work on side with my zmodem crate and serial terminal to accompany it (MS-DOS had better terminal apps than anything for Linux). And while ago @vbabka told me about this SUSE employee who does a software TPM in Rust. That makes also a lot of sense because IBM and Microsoft implementations are not up to today's standards (trying to state this politely as I can :-)).

There's really a lot of this type of stuff that would really deserve a rewrite so I just don't get why to focus on stuff that works and is of quality (like coreboot IMHO is). Especially in boot loader you would anyway do tons of unsafe stuff, and the actual malware facing thing is only after that, e.g. SBI implementation in the case of RISC-V (for OpenSBI it really would make sense to enable Rust on side based on experience of tailoring it recently).
1
0
2
ljs

Reply to @jarkko
@jarkko @jani @vbabka honestly the tell is whether somebody publicises something as 'X written in rust'

Rather than

'X but with better type/memory safety guarantees' etc.

The former, sadly, gets more clicks
1
0
2
jarkko

Jarkko Sakkinen

Reply to @ljs
@ljs @jani @vbabka That said I don't think this oreboot is useless. It could be used as basis to glue Rust into mainline coreboot (if that makes sense in a way or another). I just don't believe that it will live on like this... I mean it is a working of proof of concept that coreboot can utilize Rust if they ever want to, and if that ever happens, it would probably make sense to re-use some of this codebase.
1
0
2
jarkko

Jarkko Sakkinen

Reply to @jarkko
Edited 1 year ago

@ljs @jani @vbabka I’m trying to convince David (Howells) that we should seed Rust support to keyutils because it is exactly the context where Rust would work out pretty well. It would also provide governance from forks. I’m already putting together patches for this, even tho have not checked yet what David responded in IRC to this idea.

Other benefit is to be able to deprecate old rusty bash based test suite. With that change we could start using something like rstest to build up more comprehensive test suite. Also Rust test suite is easier to deploy to a BuildRoot image to run kernel tests.

These bash/autotools test suites are terrible for any SoC type of stuff tbh. They should be IMHO deprecated in almost any possible project… They also add up to the security risks because less test suite is run, more likely bugs will leak in. The only nicely aged test suite I know is kselftest which packages easily to anywhere :-) It’s not perfect but we should be happy that we have it…

0
0
2
About social.kernel.org

Terms of service

  1. Please do not use this service in violation of the Linux Kernel Code of Conduct. Doing so will result in your account suspension with the referral of the matter to the CoC committee.

  2. "Repeating"/"boosting" someone else's status on this platform will be treated as endorsement and will fall under rule #1.

  3. You are encouraged to use this platform to promote your work on the Linux Kernel, but there is no restriction on permitted topics (with the exception of anything covered by #1 above).

  4. There is no requirement to post in English, but it should be considered the primary language of communication on this platform.

Privacy notice

The admins of this service have access to all posted statuses. They aren't looking, but if it's something they shouldn't know about, then you should not post it on this platform.

Please see the Linux Foundation Privacy Policy, which applies to this platform as well.

Getting your own account

If you would like an account on this instance, please check that the following applies to you:

  • You are listed in MAINTAINERS or CREDITS

  • OR: You have a kernel.org account or email address

  • OR: You have a long and established history of involvement with the Linux Kernel

If the above is true and you agree with the Terms of Service and Privacy Notice listed above, please use these instructions to request an account: