FWIW, the company title at present (wasn't always the case) is 'Arm' and not 'ARM'.
https://www.arm.com/company/policies/trademarks/guidelines-t...
3,018 karma · joined February 22, 2020
https://www.arm.com/company/policies/trademarks/guidelines-t...
I think using the Rust-for-linux wrappers to implement the drivers in Rust would eventually help.
Also, even if initially Linux C drivers were transplanted into Kerla that could be a net benefit if the tradeoff of wide device driver availability vs increase in the trusted compute base was acceptable.
I personally think that tradeoff would be acceptable - if the transplanting ability was tractable. It's a hard one to absolutely agree on, admittedly.
Towards the minimal set of hardware, fair point! I think that one should be able to get quite far with judicious selection of device driver classes and leave the truly in-flux classes alone ?
My take away was that while 'new' driver classes/subsystems do involve more churn in the core kernel support subsystems, there is a clear trend towards convergence in terms of significant change.
If the change truly was significant and continuous then that would impede productisation with the Rust kernel. I'm not saying that the A{B,P}Is are in any way stable but I personally don't think that keeping up will be an intractable problem.
In the spirit of Kerla's authors prime motive - which appears to be hacking for knowledge - this might be something to try, perhaps with a driver class that is known to be more stable.
See: https://lwn.net/Articles/862018/
The issue of Rust's LLVM based compiler toolchain not targeting all CPU archs is intended to be solved by the gcc-rs project.
See: https://lwn.net/Articles/871283/
I think the approach the Rust for Linux project is taking is wise: Not about outright re-writes but more about focusing on those subsystems where Rust's intrinsic safety and security properties helps the most.
While I completely agree that NetBSD's Rump kernel would be a great way to go (I've played with it in the past and quite like it!) I do wish there was a similar initiative bound to the Linux kernel.
The closest I've seen is Octavian Purdila's Linux-Kernel-Library project: https://lkml.org/lkml/2015/11/3/706
Not sure how far they've come though. Perhaps Kerla could be a prime mover for them ?
I think a killer feature would be to emulate the Linux kernel device driver model such that existing C driver modules could be used with Kerla. Further, borrow (no pun intended!) the Linux device driver Rust wrappers from the Rust for Linux kernel project to then enable writing Linux device drivers in Rust.
The question is whether emulating the Linux device driver model (by which I kind of mean mimicking the set of core kernel services needed to support drivers - kernel threads, sync primitives, allocators etc) ends up being a massive task akin to writing the core kernel itself.
I think there might be reasonable trade offs that make the problem more tractable.
Having the ability to have a significantly simpler kernel with Rust’s memory and thread safety guarantees plus the ability to use even a small set of Linux’s massive set of drivers would be very compelling.
The core team helped set the context and begin the process of understanding what Tiers meant and what the gaps were for AArch64 Linux.
Ultimately the approvals had to come from those 3 teams. I was particularly pleased with how well structured the process was!
For AArch64, you are absolutely right, there's a lot of useful targets already ascending the Tiers, aiming to get to Tier-1.
All this will help AArch64 in particular to ge the top-class CI focus that the Rust community has built. Bodes very well for safety and security sensitive ecosystems, IMO.
Attaining this ‘badge’ is significant for Rust’s future though in a world where AArch64 Linux is astonishingly predominant especially in areas where Rust’s safety properties are a good fit.
I'll be pinging all the relevant folks soon-ish (we're pushing out fixes to the last remaining compiler test suite failures this week).
I mean to keep you on CC as I did the last time!
Of course. You may have misunderstood my intent - I'm not disputing Ada's strengths or it's penetration. I'm asserting that it does not have the same degree of general purpose appeal that Rust has today.
"Yes the open source around Ada is not that big, not all programming languages need to embrace free beer to stay relevant, if they have something worth paying for."
That's a very subjective opinion. I would assert that safety and security realities are forcing a fresh look at the importance of truly open source options. The mindset is now becoming more of - if you aren't doing open source then you are setting yourself up for pain - especially from a security standpoint.
"Right now, they have the certified compilers, ISO standards (open source consensus-by-merit does not do high integrity computing), IDEs, debuggers, and 40 years of experience deploying code into production."
Please read the thread above. I'm asserting that most software is not written for safety domains. While Rust has not penetrated the ISO26262 styled domains, those domains don't represent the bulk of software written and definitely don't dictate any given language's general purpose popularity.
Further: I would say that it is far less likely for Ada to break out of it's niche and appeal to the masses the way Rust has generally speaking. Also it is far more likely that Rust will make inroads into the functional safety space and given that it's already proving value in many general purpose segments it's likely to stick.
"What irks me about Rust is statements like "Now it may be that there emerges another alternative but at present Rust has blazed a memory safety trail that I don't see anyone in a position to challenge", which resemble the meme that "Rust Evangelism Strike Force" has become."
Yes you seem to belong to the set that I was alluding to - and I mean that in a nice way. I too was in that set. On the balance of probability you will find that there is no need to get irked once you decide to make an empirical comparison of technical and strategic strengths of the 2 languages.
Also: 'Evangelising' empirically good options is never a bad thing anyway. Doing the same without any substance if definitely worth getting irked over. Not so in this case. Save your irk-cycles for something that is truly worth expending energy on - there's lots of that going around sadly.
"The only thing that this does is turn off the attention from anyone in the known about what Rust might bring into the table."
Again a very subjective and non-constructive viewpoint frankly.
"Finally, Rust's borrow checker also gets bad press, because it still considers invalid code that for a human is perfectly clear that it should compile, hence the Polonius ongoing effort. It also makes it quite hard to do any kind of GUIs without spreading Rc<RefCell<>> everywhere, hence Raph Levien efforts how to improve writing GUIs, and the regular GNOME/Rust meetings."
Agree. Partially. You're cherry picking but in this instance I think it's justified. The false positives with the borrow checker get a lot of attention. Furthermore, the Rust compiler's ability to infer memory lifetimes is evidently continually improving.
GUIs are a pain point but are now also getting attention. There are quite likely equally proportioned gaps for Ada as well. Or for any other language. Rust's larger community is definitely helping here.
"C++ has not borrowed epochs from Rust, some people were supporting a proposal, which was discussed at Prague meeting and deemed impossible to have such feature without spreading ABI breaks across TU or module interfaces."
You are quite right. It was a proposal and not a definite pick up of Rust's editions. That's still useful insight and acknowledgement of the predicament that C++ finds itself in when balancing nimbleness in terms of change and backwards compatibility. Rust has evolved a reasonable solution to it - in part because it's standing on the shoulders of giants but more thanks to the fact that it's a community consensus driven language and not a drive-by-ISO-committee language which C++ evidently is.
Rust's borrow checker gets bad press because it forces programmers to confront their unsafe programming methodology and fix it. I think it's beautiful and ends up teaching you more rather than cultivating a culture of 'let me do what it takes to shut the compiler up so I can ship the product'. I find it very disingenuous to write the language off because it strives to be militant about safety.
Oh and Ada's compiler is super testy too! It just doesn't get the same bad press simply because far too few people use Ada compared to Rust.
I personally think that the reason people fundamentally add a moniker like 'Duncan MacLeod' to Rust is simply because Rust has gotten far too many things right and that irks dyed in the wool folks. Especially given that the choice of programming language is often enough a more emotive issue than a technical one. Having been one such person myself, I see a lot of folks spout FUD as a default position when confronted with evidence of the good design choices Rust has made. This is true.
Now that does not mean that Rust is perfect - not at all. However, it's safety features, in the face of high performance - are very compelling. Once folks draw a box around the emotive aspects and start doing objective analyses, Rust does make one pause and ponder. That's the reason why there is evidently a growing sub-culture of Rust enthusiasts even within large traditionalist companies like Google, Microsoft, Intel and Arm, to name a few.
Back to the point (!) Ada simply became too niche despite aiming to be general purpose by design. Today the open source Ada community is small compared to the Rust community and I think that is a huge problem for the perpetuation of the language, irrespective of the subset of high profile folks who've switched to it from C.
A large and vibrant community is the reason why Rust's future holds more promise. The language evolves by open source consensus-by-merit (on Github!) and that's a very strong proposition for it's future. Balancing nimble-ness and backwards compatibility has worked well thanks to the editions feature (something that C++ has now borrowed from Rust).
I'd love to see Ada succeed but at present I personally think Rust stands a better chance. Time will tell.
Looking at things from a more general standpoint, there are many examples of Rust being used in production already. Admittedly as previously stated where the need for functional safety assessments aren't stringent nor is the need for a robust set of commercial grade tools. That's still a solid chunk of the market.
I think a lot of open source projects that land in commercial products don't have the same degree of quality tooling associated with commercial counterparts. That doesn't stop those products from succeeding.
On the basis of examples such as Microsoft's disclosure of the use of Rust in the Windows 10 kernel's IPC COM bridge, Google's use of Rust in OpenTitan and a couple of others that I'll need to dig up (but evidently do exist in the public domain), I would say that in the general case Rust doesn't need a 10-20 year horizon to work in the same general spaces as C. Time will tell how true that ends up being but the trend is quite clear to me (and I was a Rust nay-sayer for quite a while before actually doing a reasonably sized OS kernel port that made me see the value).
Excuse the slight meandering but you come across as the sort of person who would appreciate some of these points. The significant value add that Rust brings is compile time memory safety - something that C/C++ simply don't have or likely to in a scale-deployable manner. The security and safety stick is hitting so hard now that a lot of the traditional arguments against an upstart programming language option are now seemingly more palatable to a lot of shops. There's a lot more to Rust then just the memory safety - I often lament about how the other bits don't get enough attention. The threading is top-notch, the expressiveness as a result of functional patterns is addictive (I find myself using Rust programs as alternatives to everyday Python/Ruby scripting - 'tis true!), the generics are lean and not overwrought as C++, the composability using traits is a good middle-ground to insane class hierarchies in C++. I could go on!
Now it may be that there emerges another alternative but at present Rust has blazed a memory safety trail that I don't see anyone in a position to challenge. When C and C++ are massaged to get to a similar space, they likely won't be the same languages anymore anyway.
Speaking about performance parity as a related aside: As an admittedly crude but IMO representative example Rust is already at par or better than C and/or C++ for the only truly open and idiomatically comparable suite I could find - drum-roll...micro-benchmarks - specifically The Benchmarks Game (results publically available). Now I concede that micro-benchmarks don't represent reality but they are what _every_ compiler engineer uses first to sanitise their port (and even what a lot of processor architects use in their RTL simulations - because that's often all they can run to completion at KHz rates) and therefore have good representative value in the first order.
More representative macro-level use-case comparisons are harder but there are sufficiently many examples of higher level frameworks (web servers etc) that showcase Rust's safety and performance. Those didn't require commercial grade tooling and a fair number are being used in production today.
About ISA convergence - and talking about the low perf deep embedded end - which is where the compiler tooling is lacking - Arm has been providing zero dollar cost licenses for the past 2 years now. See Arm DesignStart Eval and DesignStart Pro. You can do Cortex-M0 and Cortex-M3 evals at 0 USD upfront cost and have pretty much the same royalty arrangement as you would with any alternative. Heck at 75K USD you can even do a Cortex-A5. Such initiatives are likely only the beginning so the trend is quite likely going to be convergence. That's all speculation I admit but the argument is a lot easier to buttress with concrete examples now.
I would urge folks to give Rust a go. Wait - that sounded like a pun! :)
seL4 may give you a formally verified kernel. However, formal verification is a dark art with very few high priests that actually understand it on the planet. Unless it becomes commoditised, it's not going to be popular. There has been some work towards that but it's still high-priest land.
Unless a significant portion of the software that runs on top of that microkernel is also formally verified, there's always risk of many sorts.
Oh and don't forget the fact that the hardware itself is likely not formally verified so open to attack.
That's a very absolutist way of thinking and therefore not very practical I confess - but hey I was playing devil's advocate.
If the Sealed Rust initiative succeeds then we may have a general purpose formal provability story at the Rust-LLVM-IR boundary thanks to the RustBelt project. That, in theory, will open the door to provably correct kernels and full stacks which I think is the right way to attack the problem.
True. In the context of this thread, note however that the risk of continued fragmentation when it comes to security enclave architecture has made Google open source a very good design in OpenTitan to woo not just deep-pocketed open source friendly chip vendors etc but also any scale of open source software shops to promote the tech. Google wouldn't go down this path unless it had very good ideas about the adoption of Rust in this space - irrespective of the scale of the entities involved and definitely considering the long-term viability of the language.
"If you're using a Cortex R microcontroller..."
I take your general point. However I think you may be cherry picking the functional safety argument. I agree that Rust has not penetrated functional safety ISO61508/ISO26262 domains and as such it will take a fair amount of work to get it at par with C. BTW there's efforts underway to solve that with Ferrous Systems' Sealed Rust initiative.
However - and this is a contentious one - most embedded software is not written to comply to safety standards compliant. A lot of the software that is bracketed under the 'embedded' umbrella is the sort of software where the use of C today is a problem from a security standpoint and that is where Rust's value is increasingly being appreciated. Does that more general embedded software require tooling that C has but Rust doesn't ? I'd say it's quite the opposite actually. Some of the packaging, distribution and updating ease that Rust has by virtue of it's top-class tooling is something that C shall likely never have - at the language level.
More specifically about Cortex-R: The Rust embedded working group has teams dedicated to Cortex-M (the most popular 'IoT' target) and the ecosystem there for bare-metal development or RTOS centric development is actually pretty rich. Try it. For Cortex-A less so but that's getting sorted slowly. There is a proposal to have a Cortex-R group now and I am confident that Cortex-R support will trend well. Again - the kind of generic tooling associated with embedded software - such as compilers, debuggers (both general and run-time specific - say for a given RTOS etc) - all of that exists already and the support for those will most certainly increase in the short term.
"If you're using 8051, a lower-end PIC, RX, RL78, RH850, 68k, etc, you don't have a compiler at all. That's a pretty dire situation..."
I don't disagree. I must confess I'm quite biased but I think the long term trend shall be towards a smaller set of more capable ISAs and from that standpoint I think things will converge towards the set of Arm, x86 and RISC-V, support for all of which exists in varying forms already - most very good. Totally agree that if you want to use a PIC etc then you the situation from a fundamental language support PoV is arguably dire. Personally I would future proof my design and move away from those processor choices on the double if I want to be connected - and even if not.
Overall the memory safety that C has thrust upon an increasingly unsafe and insecure planet is a serious problem and I haven't seen any real scalable counters to Rust from an open, expressive, feature-rich and performant PoV.