[HN Gopher] Rust for Linux redux
___________________________________________________________________
Rust for Linux redux
Author : akvadrako
Score : 143 points
Date : 2021-07-24 09:39 UTC (13 hours ago)
(HTM) web link (lwn.net)
(TXT) w3m dump (lwn.net)
| dash2 wrote:
| I think this is gonna be a hard sell.
|
| The standard economic analysis of cooperatives is that, being run
| by their employees, they find it hard to embrace disruptive
| change (e.g. change which involves firing people). Hence, you
| probably buy your food from a shareholder-owned business, not an
| employee-owned cooperative.
|
| Linux is a bit like a cooperative in that decisions are made by
| the software engineers, not by shareholders or managers. In
| particular, most Linux contributors are probably heavily invested
| in C. If Rust gets the big boost of being allowed into the
| kernel, that could make C - and their own skills - be perceived
| as less valuable, maybe even obsolete eventually.
|
| I'll do some economic imperialism here, and claim that Rust's
| technical merits or otherwise are a second-order issue. Linux
| developers have an interest in keeping C dominant, so that will
| probably happen.
| pjmlp wrote:
| C was born to make UNIX portable (V4), so any UNIX clone will
| have a symbiotic relation with C, which kind of boils down to
| your line of argumentation.
|
| I see Rust having more success in OSes, and platforms, that
| aren't so reliant on being UNIX clones.
| jleahy wrote:
| The average Linux kernel developer is probably confident in
| 5-10 languages, and I can't imagine they would really have
| trouble picking up Rust.
|
| That kind of argument might hold for the average junior
| javascript dev, but kernel developers are normally an
| experienced bunch and C is rarely learnt today as a sole
| language.
| dash2 wrote:
| Yes, I'm sure they're extremely smart, but equally, they are
| _deeply_ expert in C, and it is not that easy to become
| _deeply_ expert in Rust (or any other language). Even smart
| people can 't just pick up new tools in a day.
| Mic92 wrote:
| They way rust is used in the kernel is a lot more
| constrained in scope and APIs compared to normal userland
| rust and hence easier to learn. A lot of added rust API are
| also just high-level abstraction of already existing
| concepts/code used in the kernel.
| paulddraper wrote:
| Be that as it may, thanks to selection bias, the vast
| majority of kernel devs still probably prefer working in C.
| tialaramex wrote:
| I think pragmatism wins. It seems _very_ likely to me that a
| safer alternative which has similar characteristics to Linux
| attracts most of the users and contributors and thus renders
| Linux irrelevant. Once upon a time it seemed like there was no
| practical way that could be done, but today not so much.
|
| This is in some sense a co-operative, but it's first and
| foremost technical. A co-operative farm feels a duty to
| consider Jim's irrational dislike of corn when deciding what
| the farm should grow. On the one hand, this land is very
| suitable for corn, there is a need for it, and they have all
| the equipment, on the other hand, Jim hates corn. But the
| technical focus means that although Jim's dislike of corn is
| _respected_ in the LKML, it doesn 't override the technical
| decision that clearly we should grow corn.
|
| Among non-experts you can end up with lengthy arguments about
| how "good" C programmers don't make the mistakes Rust defends
| against. Those arguments won't last five minutes on the LKML
| because everybody there considers themselves a "good C
| programmer" and has made those mistakes.
|
| One big technical obstacle to Rust was allocation. In C all
| your allocation is explicit, so that's kernel policy. A line of
| code that seems to simply assign a to b, for example, must not
| in fact secretly allocate resources. The ordinary day-to-day
| Rust you write does have some implicit allocation, but the
| Rust-for-Linux people landed changes so that you can have core
| and much of alloc in Linux but lose features that have implicit
| allocation.
|
| Unless there's a hitherto unforeseen technical blocker, Rust in
| Linux seems inevitable at this point. They have a list of
| unstable features they're requiring -- expect over the next
| months either things get crossed off (having meanwhile become
| stable) or removed from Rust-for-Linux in favour of an
| alternative. Unlike Firefox I'm guessing Linus has no appetite
| for living on the bleeding edge, so I think once Rust-for-Linux
| is just stable Rust, it'll make its way towards the Linus tree.
| encryptluks2 wrote:
| I'd honestly just prefer Rust to have a separate patched kernel
| and not to have it mainlined.
| mattashii wrote:
| Could you clarify? It seems to me that a build option is
| preferable to needing to maintain/checkout a seperate branch
| altogether
| encryptluks2 wrote:
| Many distros ship hardened and patched kernels. As long as
| the distro provides packages it wouldn't really be any extra
| work.
| remexre wrote:
| It being a build option doesn't preclude distros shipping
| multiple packages, some with it enabled and some not?
| InTheArena wrote:
| Every now and then you see companies make insanely large big bets
| that radically change a fundamental technology because of a in
| addressable need.
|
| I'm increasingly convinced that a good chunk of MacOS/iOS
| security problems are due to the simple fact that it is very
| difficult to write correct system level code w/ C.
|
| If (and it is a big if) the performance of rust can be in the
| same neighborhood as C - and these kinks can be worked out, then
| as a architect, I think it might be time for a ideological come
| to Jesus moment/protest reformation of the kernel.
| Santosh83 wrote:
| If there is industry backing, it _will_ happen. The coming
| generation of programmers (and hence the future of the kernel)
| are nowhere as near enthused to program in C as they 're Rust, so
| this transition is inevitable given time. Especially if the
| kernel should not slowly die out over the decades, stuck
| permanently to a fossilised language.
| kortex wrote:
| > In general, I would avoid exposing Rust subsystems to C. It is
| possible, of course, and it gives you the advantages of Rust in
| the _implementation_ of the subsystem. However, by having to
| expose a C API, you would be losing most of the advantages of the
| richer type system, plus the guarantees that Rust bring as a
| language for the consumers of the subsystem.
|
| This feels like putting the cart before the horse. "we shouldn't
| integrate Rust into the kernel in a modular sort of way cause
| it's not as optimal as more thorough type-aware integration."
|
| Like, cross that bridge when you come to it, eh? The kernel is
| currently comprised of hundreds if not thousands of components,
| talking to each other via C API/ABIs. And talking to hardware is
| almost entirely ABI. That is how the kernel do.
|
| Would we benefit from more type knowledge across boundaries?
| Absolutely, but this is _hard_ (especially given how different
| the c and rust approaches to allocation are), and shouldn 't
| stand in the way of progress.
| zozbot234 wrote:
| Exposing a C API/ABI is also the _only_ supported way of making
| separate Rust crates that can be truly interoperable beyond the
| constraints of a single rustc build. It 's not a limit to high-
| level interfaces because one can always build those as higher-
| level layers within a single crate, and there are tools
| (bindgen and cbindgen) to make this workflow a bit easier.
| brundolf wrote:
| I agree. I've migrated multiple large codebases from a weakly-
| typed language to a strongly-typed language, and in my
| experience this is the _only_ way to do it. And it 's also not
| as bad as the OP makes it sound: you get your stronger
| guarantees gradually, and that's fine.
|
| One gotcha, though: a stronger type system encourages the
| removal of runtime checks. When doing a partial conversion,
| I've found it's best to leave any existing runtime checks in
| place, even if the type system makes them "redundant", because
| it doesn't really until the calling code has also been
| converted. Once it has, you can go back and remove them.
| brundolf wrote:
| (Clarification that these codebases were obviously not as
| large as Linux, and I don't mean to imply that the job was
| anywhere near the same scale as this one would be, I just
| think some of the same lessons are broadly applicable)
| phendrenad2 wrote:
| I understand what the kernel devs are afraid of. Rust needs to
| demonstrate beyond a shadow of a doubt that it's a good
| replacement for C in the kernel, or they risk alienating people
| who don't want to learn another language, and losing those
| developers to FreeBSD or something.
| staticassertion wrote:
| > Since most of our CVE type problems are usually programming
| mistakes nowadays, the lack of review could contribute to an
| increase in programming fault type bugs which aren't forbidden by
| the safer memory model.
|
| That's an odd statement. What CVEs _aren 't_ due to programming
| mistakes? I'm not sure if the majority of CVEs for the Linux
| kernel come down to memory safety, though I would not be
| surprised, but certainly a huge number are.
|
| > without a clear and obvious benefit beyond promises that can
| only truly be fully fulfilled with a whole kernel written in
| Rust.
|
| That's not true, really. You don't need a completely safe kernel
| to have an improvement to safety. If every device driver were
| memory safe tomorrow we'd be better off.
|
| That said, I think this will be an interesting, possibly losing,
| battle. The Linux Kernel is extremely monolithic, it has a lack
| of testing and code review, decades of dug-in investments, and a
| strong history of not prioritizing security or even considering
| it to be a legitimate goal. Fixing that seems like it will itself
| take decades, whereas the current approach really feels like it's
| trying to get it done ASAP.
|
| If they can do it, cool. As a Linux user I'll possibly benefit.
| I'm curious to see how it plays out.
| wiz21c wrote:
| I tend to see Linux with rosy glasses, so :
|
| > a strong history of not prioritizing security or even
| considering it
|
| is that really true ?
| freedomben wrote:
| No. Security is important and definitely considered.
|
| Some years back there was a viral blow-up where Linus
| basically said, "security is important but there are lots of
| things that are important." A lot of people in the security
| field decided that meant "not even considered" even though
| that's ridiculous. Linus has always had a pragmatic, holistic
| approach to the kernel, and many specialists hate that
| because they think their field is the most important and all
| others should be second.
|
| If security wasn't even considered, would Linux really have
| become the de-facto base on which high security orgs (banks,
| 3 letter gov agencies, etc) deploy? I doubt it very much.
|
| As a security engineer who has seen egregious security
| malpractice on the part of developers, I fully agree that
| there can be a real problem with that. However I think it's
| silly to suggest that the Linux kernel has a history of not
| even considering security.
| staticassertion wrote:
| You've built a straw-man for my statement and you've
| completely mischaracterized Linus.
|
| Linus had multiple statements that won him pwnies, but what
| I'm referring to is decades of mailing list posts where
| he's insulted researchers, or decades of him and Greg
| rejecting CVEs and hiding vulnerabilities, etc. This has
| persisted even today, mostly from Greg, but in a less
| public way than it once was due to cultural shifts.
|
| Make no mistake, Linus and Greg have always had a hostile
| relationship with security researchers.
|
| > many specialists hate that because they think their field
| is the most important and all others should be second.
|
| Another straw man. I never said anything like this; that
| security should be the number one priority or that anything
| else shouldn't be a priority.
|
| > would Linux really have become the de-facto base on which
| high security orgs (banks, 3 letter gov agencies, etc)
| deploy? I doubt it very much.
|
| Is this satire? Are we really going with "Banks deploy
| Linux... therefor it's secure" ? Did you know banks also
| run Windows XP on their ATMs?
|
| Linux has had external contributions to security, yes. Much
| of that has been _despite_ upstream, and with immense work
| across decades to get upstream to play ball.
|
| > However I think it's silly to suggest that the Linux
| kernel has a history of not even considering security.
|
| Sorry but the only way for this to be the case is to simply
| not know the history of the Linux kernel.
| sennight wrote:
| Do a quick search of the terms: Linus Torvalds security. Pick
| any one of the results. While some of his points with regard
| to utility vs security seem to have merit... when you switch
| out "secure" with "correct" the problem becomes pretty
| obvious.
| _wldu wrote:
| I believe the author meant "logic mistakes". I agree the
| current wording is confusing.
| staticassertion wrote:
| I agree, though I wondered if that was actually true - I
| don't think so? But I don't know.
| est31 wrote:
| The question whether a logic bug can be turned into an
| exploit depends on the domain of the program. An image
| format decoder written in safe Rust might yield a pixel in
| a different color due to a logic bug, but that's the worst
| impact it can have. In software reasoning about security
| constraints however, a logic bug can mean the user now has
| root privileges, can write to /etc/shadow as an
| unprivileged user, or the TLS certificate is considered
| valid for the domain even though it isn't.
|
| Rust's safety promises don't prevent logic bug CVEs in the
| kernel. But I think it would be a major improvement if the
| kernel were written in mostly safe Rust.
| jcranmer wrote:
| > What CVEs aren't due to programming mistakes?
|
| Shellshock would be a good candidate: Bash is designed to be
| able to pass around some amount of shell scripting in
| environment variables, which obviously leads to some pretty
| severe security issues if attackers can control environment
| variables (say, CGI scripts). So you can argue that the problem
| here is a design mistake rather than a programming mistake.
| ungamedplayer wrote:
| Also, spectre meltdown, all the hw cves, there are a bunch of
| bluetooth protocol flaws.. the list goes on.
| quietbritishjim wrote:
| > > Since most of our CVE type problems are usually programming
| mistakes nowadays, the lack of review could contribute to an
| increase in programming fault type bugs which aren't forbidden
| by the safer memory model.
|
| > That's an odd statement. What CVEs aren't due to programming
| mistakes?
|
| I guess they meant as opposed to higher level design mistakes.
| CraigJPerry wrote:
| >> it has a lack of testing and code review
|
| Is that really true? I mean my first reaction is that the
| linked article / thread is a direct counterpoint. All the
| review and testing the rust facilities are going through.
|
| Are these changes not going through substantively the same
| process as other proposed changes to the kernel?
| rocqua wrote:
| On testing, linux does not come with a suite of regression
| tests.
| cesarb wrote:
| > linux does not come with a suite of regression tests
|
| https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/li
| n...
| staticassertion wrote:
| No, what we have here is definitely more of an exception -
| sort of like an RFC for larger changes that could take months
| or years to play out. The vast majority of code changes do
| not go through this.
| geofft wrote:
| The fact that a process is _burdensome_ does not mean it is
| necessarily _effective_.
|
| Look at the seq_file thing Qualys discovered the other day.
| The overflow was obvious if you thought about it, and all
| Qualys did was think about it. But the bug was present since
| 2014.
|
| https://www.qualys.com/2021/07/20/cve-2021-33909/sequoia-
| loc...
|
| Linus's law is empirically untrue for security bugs - many
| eyes don't actually spot them. Moreover, we have computers,
| which are good at doing repetitive and detail-oriented tasks
| with 100% accuracy. Why not use them?
| bowyakka wrote:
| Hmmm while I agree with you, doesn't the fact qualsys went
| looking out eyes on it? We sure that a seq_lock bug isn't
| present in say OSX, QNX, Windows?
| medstrom wrote:
| I don't think it lacks code review, it's famously hard to get
| half-baked stuff through Torvalds.
| staticassertion wrote:
| That isn't really true.
| wott wrote:
| The ton of driver code that piles up in the Linux kernel
| every minute doesn't go through Torvalds. It is delegated.
|
| And my reviewing of a few drivers source short commits is
| enough to tell me that those delegates do not perform a
| satisfyingly thorough review by any mean.
|
| Heck, I saw patches of just a couple dozen lines which
| exhibited bad copy-pasting errors anyone without prior
| knowledge could have spotted. You don't need to know what
| the code does to spot some, you don't either need to know
| what the driven device does to spot some: purely formal
| errors with bad macros definitions for example. This kind
| of stuff wouldn't even pass the first internal review where
| I worked, which just looked at formal appearance (then
| there were more in depth reviews, and then there was an
| external review, but we'd make as sure as possible that our
| code would be clean before going out).
|
| So first you have people (employees of company A) which
| sends code to a public, external project without having
| done a proper internal review. Then you have someone else
| (employee from company B) who claims to have reviewed the
| commit but hasn't done it properly or at all. And then
| possibly a third someone who validates this, but doesn't
| actually check either. It has become a job, a task like
| another, with the same people who do the same sloppy job as
| quickly as possible to get rid of it and go home earlier or
| slack, in the same proportion that you can find in any
| other position in the world.
| Mic92 wrote:
| They don't even do CI when reviewing patches. Some of the
| code they review on mailing lists does not even compile.
| mrtweetyhack wrote:
| CVE-2021-36934 MS SAM file can be read by anyone
| medstrom wrote:
| With all its build options and modules, the traditional
| monolith-microkernel distinction doesn't really apply. Do you
| mean something else by "extremely monolithic"?
| akiselev wrote:
| It's not so much the Linux kernel that's monolithic, but the
| Linux source code. Since drivers gets mainlined, they become
| part of the Linux stability guarantee. When a significant
| fraction of the source code is drivers for specialized
| devices (i.e. AMD GPUs), the development process takes on the
| characteristics of an extreme monolith that requires
| coordination of many different teams.
| paulddraper wrote:
| > a strong history of not prioritizing security or even
| considering it to be a legitimate goal
|
| ?
|
| Did you mean the Windows kernel?
|
| Linux has had incredible focus on security. SELinux being a
| prime example.
| staticassertion wrote:
| No, Windows has by far more investment into security and a
| far better culture. Linux has a multiple-decades-long history
| of saying that security is not important and has had to be
| dragged kicking and screaming to modernity.
|
| SELinux is just an LSM built decades ago, I wouldn't say that
| somehow proves that upstream cares about security.
| [deleted]
| pjmlp wrote:
| Actually, not really, one has to look for Android, if wanting
| a Linux kernel with all the proper security knobs actually
| turned on and configured appropriately.
|
| In an OS where Linux kernel is actually an implementation
| detail in what concerns userspace.
| alexjplant wrote:
| Probably a mischaracterization of Linux on the basis of
| Linus's infamous comment on OpenBSD devs [1].
|
| [1] https://lkml.org/lkml/2008/7/15/296
| paulddraper wrote:
| Wow, excellent stuff.
|
| > To me, security is important. But it's no less important
| than everything _else_ that is also important!
|
| > - Linus
| trulyme wrote:
| With all due respect, Linus could learn some manners:
|
| > I think the OpenBSD crowd is a bunch of...
|
| Apart from that, if there is no test coverage it is
| difficult to talk about security or reliability (I don't
| know myself if there are tests and how good they are, I'm
| just assuming GGGP is right).
| akiselev wrote:
| _> Linus could learn some manners_
|
| He acknowledged that and did so, years ago.
| trulyme wrote:
| I assume this was after the linked post then, and it's
| good to hear that. The problem is that these posts stay
| online for a loooong time. Thanks for answering.
| paulddraper wrote:
| > What CVEs aren't due to programming mistakes?
|
| Spectre
| woodruffw wrote:
| I think there's a strong argument to be made for Spectre
| being a programming mistake, with the programming in question
| being Intel and AMD's proprietary microcode formats. We'd
| consider a similar timing/information channel in C to be a
| programming mistake, so it's not clear why we should exclude
| one in a lower-level representation.
| cesarb wrote:
| > with the programming in question being Intel and AMD's
| proprietary microcode formats
|
| No, as far as I know, the design mistakes which lead to
| Spectre (and other similar vulnerabilities) are not on the
| microcode; these design mistakes are on an even lower
| level, in the hardware structures which execute both simple
| instructions (which are decoded directly, without going
| through the microcode engine) and microcode instructions.
| Most of what the microcode "fixes" for Spectre and similar
| do, is flipping a few "chicken bits" (to disable or bypass
| some of the hardware structures), and providing extra
| semantics to a few of the complex instructions (which go
| through the microcode engine) like LFENCE and VERW; these
| changes do not actually fix the problem (which is on
| physical hardware), but instead give software ways to
| workaround the issue.
|
| You should argue instead that the programming in question
| is the VHDL or Verilog (or other proprietary language)
| which was used to generate the hardware.
| xxpor wrote:
| Is writing verilog/vhdl programming?
| pjmlp wrote:
| Looks like C and Ada dialects to me.
| robertwt7 wrote:
| It is good that rust is slowly being adopted everywhere. Gives me
| more reason to learn it..
| cesarb wrote:
| In my opinion, you should learn Rust even if it doesn't get
| adopted everywhere. My experience is that learning the coding
| style enforced by the borrow checker (having to think about
| whether a piece of data is "owned" or "borrowed", whether it's
| an exclusive or shared borrow, whether it's safe to send or
| access it from another thread) makes you a better programmer in
| other languages.
| wiz21c wrote:
| Rust helps a lot with memory or concurrency issues. But not the
| rest. And in my experience, although the concurrency/memory
| issue are surely the most time consuming bugs, the "rest" is
| what takes 90% of the time...
| kortex wrote:
| To each their own. I find Rust a huge step up from C and even
| C++... _especially_ C++. I 've been writing Rust for months
| and C++ for years. I still feel more comfortable and
| confident my Rust code has fewer bugs and does what I intend
| vs C++.
| _huayra_ wrote:
| I would say that 90% of the bugs are just logic issues, but
| there is a heavy tail of devious bugs that will take 90% of
| the time, even if they don't surface right away.
|
| Although I still haven't really played around with Rust yet
| myself (still trying to grok the new C++20 features in recent
| weeks), the fact it puts your code into a (sometimes
| admittedly annoying) sandbox to prevent these bugs could be a
| godsend.
| pjmlp wrote:
| It should be noted that memory in cases where automatic
| memory management cannot be afforded, and concurrency only in
| what concerns in memory data structures.
| viraptor wrote:
| There's more that it helps with. For one example Rust's Enums
| and richer types allow fewer mistakes -vs- confusion where
| pointers and integers degrade to a common type. A random
| line: https://github.com/torvalds/linux/blob/122fa8c588316aac
| afe7e...
|
| > void crypto_aead_clear_flags(struct crypto_aead *tfm, u32
| flags)
|
| These are valid due to poor type usage, but make no sense:
| crypto_aead_clear_flags(..., PAGE_SIZE)
| crypto_aead_clear_flags(..., EBUSY)
| crypto_aead_clear_flags(..., SOME_RANDOM_THING)
|
| We can hope they would be caught in review if the code
| happens to do the right thing by accident, or use static
| analysis and hope it triggers in that case, or use a language
| with clearer types where it's much easier to use types
| preventing this issue.
| pjmlp wrote:
| You could the same with C++ or Ada, but naturally it will
| never be a thing in Linux.
| woodruffw wrote:
| Ada can do that, but C++ arguably makes things even worse
| than in C: apart from supporting a subset of C's
| misbehavior, it introduces implicit-by-default converting
| constructors. Those make API misuse _very_ easy.
| pjmlp wrote:
| Experience in Apple and Microsoft platforms, among
| others, shows otherwise.
|
| And for info, Android Treble drivers are mostly C++,
| although Java is also an option.
|
| Ah and Fuchsia is a mix of C++ and Rust at it lower
| layers.
| scudd wrote:
| In general I find I'm productive in Rust; however, I do agree
| that there are some features that produce more confusion and
| debugging than others. For me it seems to be async and
| dynamic dispatch that are tricky.
| Zababa wrote:
| Compared to plain C, you have ADTs which help from day to day
| programming. You can bring them to C
| (https://github.com/Hirrolot/datatype99) but I don't know if
| the Linux guys would allow it.
| frazzyfraz wrote:
| This is just a non-clever attempt by double-vaxxed NPCs to SJW
| Linux over.
| ayane_m wrote:
| The FUD around Rusting the kernel reminds me of similar
| sentiments surrounding autonomous vehicles. Better != perfect;
| it's an evolutionary step. Even if there are unintended negative
| consequences of Rust code, if they are less frequent than the
| rate we deal with bugs today, then it's worth using.
| sidlls wrote:
| Then maybe the Rust community would be better served by not
| hyper-evangelizing it so much and at the same time bashing
| other languages?
|
| There's a perception issue here: people think that Rust people
| (not necessarily the maintainers or official evangelists, but
| the community at-large) think Rust is as close to perfect as
| you can get because of its safety features, because these
| people talk about Rust like it's a universal problem solver.
| jmull wrote:
| It seems pretty clear that rust in linux would reduce certain
| kinds of run-time bugs. What isn't so clear is whether,
| overall, rust improves linux or not.
|
| There's bad to be weighed against the good. Adding complexity
| strains and breaks processes, slowing development. Among other
| things, this means additional bugs and lets them survive
| longer, so it's not even clear rust is a win purely from a bug
| perspective.
| diragon wrote:
| Rust in Linux has a known constantly showing negative
| consequence: it introduces another language to the stack.
| Furthermore, Rust is quite different from C. This makes the
| whole massively more complicated, and increases the amount of
| knowledge needed to understand the whole.
|
| The same effect applies every time a new language is
| introduced, if it doesn't completely replace the previously
| used language. In this case, Rust won't.
|
| Zig might be a better fit, given how much more similar to C it
| is.
| geofft wrote:
| Why is it a bad thing that Rust requires you to learn more
| things? As 'mjg59 pointed out recently, the kernel dev
| community intentionally asks you to learn more things
| _unrelated_ to your code as a means of keeping the "bar"
| high and fielding only committed contributors. Isn't it all
| the more reasonable to ask people to learn a programming
| language?
| https://twitter.com/mjg59/status/1413406419856945153
|
| Rust isn't terribly hard to learn, especially for a kernel
| developer with a good understanding of C and of memory. You
| can pick up the basics in probably an hour. A lot of its
| design choices match approaches the kernel already takes
| (traits are like ops structs, errors are reported via return
| values, etc.)
|
| And Rust is a language that plenty of college students pick
| up for fun. Professional kernel engineers should be able to
| learn it just fine. Frankly the hardest thing about Rust is
| that it makes you think deeply about memory allocation,
| concurrent access across threads, resource lifetimes, etc. -
| but these are all things you have to think deeply about
| _anyway_ to write correct kernel code. If you have a good
| model for these things in C, you can write the corresponding
| Rust quickly.
|
| In fact, learning Rust and thinking about Rust's concurrency
| rules has made RCU a lot easier for me to understand. RCU is
| famously a difficult concept, but the kernel uses it
| extensively and expects people to use it. So "requires little
| knowledge and is easy to understand" is not an existing
| design goal of the kernel - but having people pick up Rust
| might help there anyway.
|
| (Zig seems like an entirely reasonable choice too. Send in
| some patches! :) )
| pjmlp wrote:
| Zig's syntax has nothing to do C, and overdoes it with @
| everywhere.
|
| Until it fixes use-after-free, better keep using C anyway.
| jorangreef wrote:
| What Zig shares with C is orthogonality, with a large
| power-to-weight ratio, meaning it's a small language
| grammar with powerful range.
|
| But Zig also improves on C's safety in many ways, not least
| checked arithmetic enabled by default in safe release
| modes, along with bounds checked memory accesses, function
| return values that cannot be ignored, checked syscall error
| handling, explicit allocations, comptime over macros, a
| short learning curve and remarkable readability.
|
| It's hard for systems programmers not to appreciate any of
| these qualities in isolation.
| pjmlp wrote:
| A brilliant language wouldn't stuffer from use-after-free
| in 2021, or use file import as module concept.
| capableweb wrote:
| > Rust in Linux has a known constantly showing negative
| consequence
|
| It'd make your argument a lot stronger if you can actually
| list some of these negative consequences. "Another languages
| to the stack" and "Different than C" is just complaining
| about change because it is change.
|
| What negatives have already been shown that isn't just about
| "This isn't C"?
| rollcat wrote:
| Mixing any two languages in any single code base creates
| significant friction at the boundaries, and adds new
| degrees of complexity in major areas (build system,
| tooling, debugging...). If we're talking about a project as
| complex as a production OS kernel, this kind of a decision
| should never be taken lightly. It's a much smaller step
| from 2 to 10 than from 1 to 2.
| cesarb wrote:
| > It's a much smaller step from 2 to 10 than from 1 to 2.
|
| But here, you're already starting with 2: C and assembly.
| Besides inline assembly, a small but very important part
| of the Linux kernel is written in assembly on every
| architecture: the system call entry point (entry.S) and
| the kernel entry point (head.S). And if you consider each
| architecture's assembly as a separate language, it's more
| like 10 languages than 2 languages. I'm always impressed
| whenever I see changes to for instance signal handling or
| thread flags which touch not only the common code in C,
| but also the entry point assembly code for each one of
| the many architectures Linux supports; whoever does these
| changes need to not only know the assembly language for
| all these architectures, but also have at hand all the
| corresponding tooling and emulators to compile and test
| the changes.
| rollcat wrote:
| You do have a point, however (as you noted) the lowest-
| level bits of an OS kernel are practically impossible to
| build (and subsequently, maintain) without precise
| control over the machine code; you can't even start a
| hobby OS kernel project without relying on assembly. It's
| a part of the deal; a pure-assembly kernel is more
| feasible than one without any. You also (as you pointed
| out) still have to be mindful about the C-asm boundary;
| the integration doesn't come free.
|
| The story here is pretty different: integrate a new,
| _high-level_ language into a 30 year old, 30mil SLOC,
| production code base, that billions of people rely on
| every day, AND actually extract some value from that
| work.
| bitwize wrote:
| We, the global community of software developers, are in the
| process of putting C out to pasture, with Rust as the de
| facto front runner as a successor. At this point it becomes a
| question of either admitting Rust into the kernel or,
| eventually, using another kernel written in Rust.
| paulddraper wrote:
| > The FUD around Rusting the kernel reminds me of similar
| sentiments surrounding autonomous vehicles
|
| That, but in the opposite direction.
|
| Decades of promises of self-driving cars. And still nothing
| able to drive without a driver.
|
| There have been small improvements...cars that have autonomous
| abilities in some cases.
|
| But overhauling the entire driving fleet of the world to use
| 5-year-old technology....it's not a realistic expectation.
|
| There are smaller, more practical expectations.
| ben-schaaf wrote:
| > Decades of promises of self-driving cars. And still nothing
| able to drive without a driver.
|
| Waymo have driven 20 million miles autonomously since 2009,
| and as of late 2020 claim 74,000 of those were done
| completely driverless. They're still a far cry from being
| common, but they're here and they're impressively safe.
| shakow wrote:
| But what is the "miles on straight-ahead, well-lit US
| highway" vs. "kms on random European regional road" ratio?
| simion314 wrote:
| We need to keep in mind that are 2 types of autonomus vehicles
| discussion. We have a company that uses a ton of hardware,
| radar, lidar and many cameras and then we have the other ones
| that want to move fast and break things using only cameras, a
| GPU and many beta testers. It is normal that the aproach of
| brute forcing it with ton of data gets a ton of criticism.
|
| My other criticism is the bad statistics used. It is like I
| create the "robot athlete" and I compare it stats with the
| average of all athletes including the young children and the
| people with some physical problem. You should compare self
| driving with cars with exact same safety features and save
| driver demographics. Bonus if you calculate all deaths caused
| by illegal driving and then ask the giants WTF not put the
| money into first solve the speeding and drunk / tired driving ,
| I bet ANN work better on this problem.
|
| Rust in Linux seems to me a waste. IMO the Unix philosophy is
| great but it needs a better implementation , one that is based
| on the present day hardware and expectations.
| greatgib wrote:
| For me, the issues with Rust are:
|
| - It is not fun but frustrating to work in Rust, and contrary to
| C, you are limited by the language/compiler on what you can do.
|
| - building/compiling the kernel is not trivial, and you will add
| a new huge dependency that you have to deal with to build the
| kernel for whatever target. Let's suppose you want to build for
| MIPS, then you need to have Rust supporting MIPS.
|
| As an exemple, there is a common package in python that decided
| to start having their module in Rust instead of C. Now a lot of
| users of the module are pissed off, with good reason, because you
| can't build/install the module anymore in a little bit older or
| non conventional distributions.
| pjmlp wrote:
| > - It is not fun but frustrating to work in Rust, and contrary
| to C, you are limited by the language/compiler on what you can
| do.
|
| That depends on the beholder.
|
| Developers that grew up in Algol derived languages like Modula,
| Pascal and Ada, feel Rust brings fresh wind into systems
| programming, with safety considerations we thought it were lost
| forever and only partially covered by C++.
|
| Then there are the others like Kernighan, that feel that
| languages like Pascal, sorry Rust, is programming with a
| straightjacket and better not change anything.
| wiz21c wrote:
| You are not limited. You are strongly driven. It's different.
| Painfully different, I agree. But as time goes by, it becomes
| painful.
| choeger wrote:
| The latter point is an important one. Rust as a language for
| libraries cannot work the same way as rust as a language for
| applications. For the latter it is OK to depend on the cargo
| toolchain and be opinionated when it comes to things like
| dynamic linking. For the former you ideally want support in any
| common compiler (clang, GCC) and as little dependencies and
| constraints as possible.
| jhgb wrote:
| Even if you're compiling dynamic libraries/.so's with a C ABI
| to be consumed through a C FFI from another language? That
| seems to be fairly common use case these days, and I don't
| see those issues there (unless I've missed something, which
| is of course very possible).
| zozbot234 wrote:
| Rust itself largely supports this (via the 'cdynlib'
| project type), however for many Rust crates it either does
| not make sense to export a pure C API/ABI (i.e. the
| "crates" are purely generic code that's going to be
| instantiated with build-specific types, so there's no
| predefined API beyond that single build) or they just don't
| bother to enable that use case.
| jhgb wrote:
| Well, sure, language-level API (with a type system
| identical to Rust's) will be a problem, but as long as
| there's only one compiler, there doesn't seem to be a
| problem -- yet. I'm mildly wondering if this isn't a
| chicken and egg problem of sorts.
| bsdubernerd wrote:
| It's also a problem for application themselves IMO. Cargo
| combined with dependency pinning brings most of the
| disadvantages of similar environments with centralized
| package handling: the ease of adding package dependencies
| increases the number of dependencies themselves very rapidly.
| Overly-narrow version pinning forces per-package lockstep
| updates of the various dependencies, which in turn means
| multiple versions of the same package will get pulled two-or-
| three levels deep. This ensures each single rust package or
| update you build is almost a guaranteed rebuild-the-world
| even with a shared cache dir. And we're not touching the
| problem of building projects where rust is only part of it:
| annoying if you want to link other stuff into rust, even more
| so if you want to do the opposite.
|
| I'm following a couple of projects that transitioned to rust,
| and my experience as a contributor is not stellar. A minimal
| rust project can take hundreds of mb of disk space just in
| dependencies, and double that for build space. The solution
| for some has been providing build bots, but again doesn't
| help me as a contributor, where I need to be able to rebuild
| from source.
|
| This has on me almost the same effect produced by large
| projects: I only contribute if I have a large vested interest
| in the package, otherwise I just avoid because it's time
| consuming.
| kortex wrote:
| Cargo != rust. They are different things for a reason. You
| don't ever need cargo to manage deps or build, it's just
| idiomatic to do so.
|
| Nothing stopping you from building rust code with manual
| vcs, rustc, autoconf, and make, just like C.
| bsdubernerd wrote:
| Yes, however they're much more tied together as an
| ecosystem than, say, python and pip.
| steveklabnik wrote:
| Notably for this thread, Linux will not be using Cargo.
| jhgb wrote:
| Is there any sort of detailed documentation on how to use
| rustc directly in more complex ways? I imagine that any
| begginer's text will mostly treat cargo and not such
| special usage scenarios as this one.
| steveklabnik wrote:
| https://doc.rust-lang.org/stable/rustc/ is the rustc
| specific documentation.
|
| You can pass -v to Cargo and it will show you the rustc
| invocation it makes if you want to reverse-engineer what
| Cargo does.
| pjmlp wrote:
| You can read how Google is going to do it, regardless of
| what upstream decides to do.
|
| https://security.googleblog.com/2021/05/integrating-rust-
| int...
|
| https://security.googleblog.com/2021/06/rustc-interop-in-
| and...
| kortex wrote:
| Thanks for clearing that up. Say, you know a lot of
| things about the rust ecosystem. Do you have any insight
| into how hypothetical rust driver code would integrate
| with the rest of the kernel build process? I imagine it
| would have to use llvm-rustc, or is gccrs ready for the
| job?
|
| Would it be emitting objects that gcc/ld would link
| against?
| steveklabnik wrote:
| > Do you have any insight
|
| Well, this is a working patch set, so, yes, though I have
| no direct involvement and haven't read all of it yet.
|
| > I imagine it would have to use llvm-rustc,
|
| Yes, it uses upstream rustc.
|
| > is gccrs ready for the job?
|
| Not yet. They're making great progress, but major chunks
| of the language are still missing. They'll get there.
|
| Using upstream rustc isn't a blocker for new code
| implementing drivers, but it is a blocker for getting
| into older drivers, or the kernel. The blocker is
| platform support; or at least, the current largest
| blocker, and either rustc will gain it, or gccrs will be
| good enough to compile this codebase. We'll see :)
|
| > Would it be emitting objects that gcc/ld would link
| against?
|
| Yep, it emits output that looks like any C compiler's
| output, you link 'em together and you're good.
|
| If you manage to compile the kernel with clang, in theory
| you can even get cross-language LTO; this is working in
| Firefox, but I'm not sure if anyone's tried it with the
| kernel yet or not.
| gspr wrote:
| True in principle. But once you divorce yourself from
| Cargo, almost all resources and advice when it comes to
| building Rust programs go out the window. I love the
| language, and I love the community, but the attitude of
| "rustup nightly and Cargo, or bust" is bit terrifying.
|
| As a noob, I had to wade through endless "but don't do
| that, just get the latest from Cargo!!!!" when I asked
| for advice on how to use my system-provided Rust packages
| for my project.
| kryptiskt wrote:
| In what way are you more limited by the compiler in Rust than
| with C? Just write "unsafe" and you're off to the races.
|
| Writing correct C is very hard and most definitely not fun.
| It's like juggling with with 7 balls and if you drop one you'll
| be shot. C is defined for a weirdo abstract machine that
| doesn't match what computers really do, and when people apply
| their intuition and knowledge about computers to their C
| programs "because C is low-level", it's a crapshoot whether
| they will trigger undefined behavior and the compiler goes off
| the rails with wild optimizations.
|
| If I designed a low-level language I would enable such
| optimizations by making it easy to communicate your precise
| intent to the compiler. Not by making the standard a minefield
| of undefined behaviors.
| tialaramex wrote:
| > Just write "unsafe" and you're off to the races.
|
| I'm pretty sure I mention this in the LWN comments, but,
| since it gets repeated so often the contradiction might as
| well be repeated as well:
|
| No. Unsafe Rust only gets to do three things that aren't
| related to the "unsafe" keyword itself. It can dereference
| raw pointers, it can access C-style unions, it can mutate
| global static variables.
|
| That's everything. Your C program is free to define x as an
| array with four elements and then access x[6] anyway - but
| Rust deliberately cannot do that. Not in Safe Rust, but also
| not in Unsafe Rust either. Writing "unsafe" doesn't mean "Do
| this anyway" it only unlocks those three specific things I
| mentioned, and so sure enough x[6] is still not allowed
| because that's a buffer overflow.
|
| In fact by default the Rust compiler would warn you, if you
| write unsafe { foo[z] = 0; } that unsafe isn't doing anything
| useful here and you should remove it. That array dereference
| either is or, if z is small enough, is not, an overflow, and
| either way unsafe makes no difference.
| drran wrote:
| > Your C program is free to define x as an array with four
| elements and then access x[6] anyway - but Rust
| deliberately cannot do that. Not in Safe Rust, but also not
| in Unsafe Rust either.
|
| Woot? fn main() { let a = [0, 1,
| 2]; let _b = [42, 42, 42]; println!("{}",
| unsafe{a.get_unchecked(6)}); }
|
| https://play.rust-
| lang.org/?version=stable&mode=debug&editio...
| Arnavion wrote:
| The claim was about `x[6]`, which does not appear in your
| program. The point is that `[]` is always bounds-checked,
| and the bounds-checking cannot be opted out of even with
| `unsafe`.
| baq wrote:
| holy goalpost batman. you've moved them to the other side
| of the world.
|
| what's next, you can't write 6[x] in rust but it's
| perfectly fine C, thus rust is inadequate?
| Arnavion wrote:
| You might want to re-read the conversation thread.
|
| Hint: I am not tialaramex, and neither of us said
| anything against Rust in our comments.
| fnord123 wrote:
| > The claim was about `x[6]`, which does not appear in
| your program.
|
| That was C code. The rust code for that was provided by
| drran.
|
| > The point is that `[]` is always bounds-checked, and
| the bounds-checking cannot be opted out of even with
| `unsafe`.
|
| I don't think anyone is hung up on whether you use
| std::ops::Index or not. You can access arrays without
| bounds checks.
| Arnavion wrote:
| https://news.ycombinator.com/item?id=27941675
|
| >No. Unsafe Rust only gets to do three things that aren't
| related to the "unsafe" keyword itself.
|
| >[...]
|
| >Your C program is free to define x as an array with four
| elements and then access x[6] anyway - but Rust
| deliberately cannot do that. Not in Safe Rust, but also
| not in Unsafe Rust either.
|
| >[...]
|
| >In fact by default the Rust compiler would warn you, if
| you write unsafe { foo[z] = 0; } that unsafe isn't doing
| anything useful here and you should remove it. That array
| dereference either is or, if z is small enough, is not,
| an overflow, and either way unsafe makes no difference.
| [deleted]
| tinus_hn wrote:
| Note that the C version of this might compile but the
| result is undefined, so it could be what you intuitively
| thought what would happen, or anything else.
|
| Not what you want in a kernel.
| geofft wrote:
| Since the conversation is claiming that you _can_ do
| everything in Rust that you can do in C, I want to provide
| some counter-nuance. :) I am guessing what people actually
| mean is that all the operations you want to do can be done
| via unsafe Rust somehow, and yes, you can do that. But also
| yes, it is not literally "just write 'unsafe'". You do
| need to use raw pointers.
|
| For instance, if you want to overflow a buffer
| intentionally, fn main() {
| let mut a = [1, 2, 3, 4]; let b = [5, 6, 7, 8];
| let ptr: *mut i32 = &mut a[0]; unsafe {
| ptr.add(5).write(999); } println!("{:?}", b);
| }
|
| produces [5, 999, 7, 8]
|
| https://play.rust-
| lang.org/?version=stable&mode=debug&editio...
|
| (Note that this is not just extremely platform-specific and
| compiler-specific about whether a is in front of b or vice-
| versa, it is straight-up Undefined Behavior because you
| write past the end of an object... but the equivalent C
| code is also Undefined Behavior, and subject to the same
| LLVM optimizations. So if you were happy with the
| corresponding C code, this is the equivalent Rust.)
|
| If you really, really want, you can write your own
| UnsafeSlice type that does the unsafe stuff internally and
| exposes the standard indexing operator, which would make
| foo[z] actually accept arbitrary indices just like in C.
| But you shouldn't. https://play.rust-
| lang.org/?version=stable&mode=debug&editio...
|
| (Among other things, a code reviewer should be suspicious
| of your use of "unsafe" in the internals of a thing without
| stating why the higher-level abstraction is safe, and in
| fact the abstraction is wildly unsafe here, so it's bad
| style to write code that launders the unsafety, so to
| speak. In the Rust for Linux patches, there are "SAFETY"
| comments above each use of "unsafe" defending their logical
| safety.)
| tialaramex wrote:
| This is a little tidier:
|
| https://play.rust-
| lang.org/?version=stable&mode=debug&editio...
|
| UnsafeSlice is a _terrible_ idea, but let us at least
| give it the normal ergonomics of a wrapper type so we can
| say UnsafeSlice( &mut a) rather than needing curly braces
| to make one :)
| kryptiskt wrote:
| You don't need anymore than that to match what C offers, C
| as in standard C, not in the folklore of C as a portable
| assembler. In fact you're freer in Rust than in C, because
| there is a simple, defined way to type-pun memory in Rust.
|
| > Your C program is free to define x as an array with four
| elements and then access x[6] anyway
|
| It's free to do anything, but you can't be sure that it
| will do that, because of the utterly weak specification.
| galadran wrote:
| > It is not fun but frustrating to work in Rust.
|
| Deeply subjective. Rust has been the most loved language on
| Stack Overflow for 5 years in a row now.
|
| > add a new huge dependency
|
| Sure, but setting up Rust is much much easier than GCC with all
| the trimmings.
|
| > As an exemple, there is a common package in python that
| decided to start having their module in Rust instead of C. Now
| a lot of users of the module are pissed off, with good reason,
| because you can't build/install the module anymore in a little
| bit older or non conventional distributions.
|
| Assuming you are referring to pyca, you are mistaken and there
| has been a lot of misinformation about the change. Rust support
| is needed to build the module, but not install it. Pyca works
| just fine for users without rust and works everywhere rust
| does. Users on niche CPU architectures which haven't been sold
| commercially for 15+ years were the only ones impacted.
| brandonmenc wrote:
| > Deeply subjective. Rust has been the most loved language on
| Stack Overflow for 5 years in a row now.
|
| How many of those votes were cast by programmers who have
| actually used the language?
| jkelleyrtp wrote:
| That particular metric is derived from "people who use the
| language outside of work and wish they could use it more at
| work." The survey doesn't explicitly say "which language do
| you love?".
| jcelerier wrote:
| Everything is more fun when you don't have to
| interoperate with Joe Coder (who left the company 7 years
| ago)'s APIs and idiosyncracies
| tialaramex wrote:
| Sure, that makes a fine hypothesis. Still though, if
| you're right, why does Rust report 86.1% love while
| Python only got 66.7% ?
|
| https://insights.stackoverflow.com/survey/2020#technology
| -mo...
|
| Maybe the Python number is smaller because those people
| are working right? All the Rust programmers are just
| working on a fun program at home, and Python is a serious
| language now, you're working the 9-5 with Joe Coder?
|
| Haskell is 51.7% though. So, I guess when I wasn't
| looking Haskell really exploded in boring office
| environments and I shouldn't expect to see any more
| hobbyist Haskell projects everywhere... or your
| hypothesis was just wrong.
|
| Maybe it's just that Rust is new and exciting, let's look
| at what people _want_ to use that they don 't now, surely
| that'll be Rust too and we'll know it's just Hype.
|
| Huh, _that_ chart is dominated by Python. 30% of
| programmers not doing Python wanted to start.
| Zababa wrote:
| You could said the same for every language.
| fnord123 wrote:
| The problem with pyca cryptography was that Python users are
| not in the habit of using lockfiles which meant reinstalling
| venvs picked up more recent versions of transient
| dependencies. That and that they made the change in a minor
| update and non wheel users got caught out.
| stevekemp wrote:
| Could also be referring to the cryptography library which
| added a Rust dependency, which caused pain for people running
| ansible, and other downstream users.
| woodruffw wrote:
| > Could also be referring to the cryptography library which
| added a Rust dependency, which caused pain for people
| running ansible, and other downstream users.
|
| This isn't true for the overwhelming majority of
| deployments, since pyca/cryptography was/is distributed as
| a pre-built wheel. There is no runtime dependency on Rust
| in pyca/cryptography; the only downstream change is that
| _packagers_ are required to have a Rust toolchain.
| geofft wrote:
| As I understand it, rustc_codegen_gcc [1], which is being
| merged into mainline rustc [2], supports building for MIPS.
|
| [1] https://github.com/antoyo/rustc_codegen_gcc
|
| [2] https://github.com/rust-lang/rust/pull/87260
|
| Can you give it a try?
| kam wrote:
| The default LLVM backend has supported MIPS since before 1.0
| as well.
| sanderjd wrote:
| Au contraire on the first point, Rust is super fun. But it
| should be clear that this is just subjective...
| kortex wrote:
| Exactly, it's subjective fun. Some people like languages
| where compiler errors point you in the right direction,
| expressive features like ergonomic strings, closures,
| syntactic macros, etc.
|
| Other folks are masochists and get their jollies from cryptic
| errors, segfault debugging, pouring through valgrind traces,
| and of course manually managing memory. If you aren't
| suffering, are you _really_ programming?
|
| I tease, but not entirely. Sometimes I do in fact enjoy the
| challenge of C programming. But it's squarely type 2 fun.
| jstimpfle wrote:
| The amount of segfault debugging and managing memory is
| roughly linearly dependent on how much you pretend to not
| be programming in C but in an object-oriented programming.
|
| Those languages give you syntax and/or runtime tools to get
| away with badly structured programmings (allocating /
| deallocating stuff like mad, lots of implicit behaviour). C
| is not like that. It wants you to think and learn how to
| structure programs (this is transferable knowledge, i.e. it
| gets much better with time).
| viraptor wrote:
| > you are limited by the language/compiler on what you can do
|
| You can translate most C to Rust automatically
| (https://c2rust.com/) and there's nothing that I'm aware of
| that can't be done in Rust via unsafe and transmute.
| (technically some things like specific label jumps can't be
| translated, but all of those can be rewritten to other
| constructs) Do you have some specific cases in mind?
| dgb23 wrote:
| How feasible is it to refactor an autogenerated unsafe Rust
| module into a idiomatic one, compared to starting with a new
| design from scratch?
| bogeholm wrote:
| Here's a blog series about rewriting some classic C in
| Rust, first unsafely and then safely, and getting some
| performance wins along the way:
| http://cliffle.com/p/dangerust/
| kortex wrote:
| That's "translate c to rust" in the same way as translating
| English to Japanese by looking up the kanji for an English
| word, and replacing it word by word. Why not just generate
| bindings at that point?
| viraptor wrote:
| I'm neither recommending to use it, nor saying it's a good
| quality result. I'm addressing the "you are limited by the
| language/compiler on what you can do" part, which for real
| code is not the case in my experience.
| kortex wrote:
| Ah, yeah I see your point. I suppose that's a useful shim
| to having full Rust interop with a pre-existing C
| codebase as you convert, or if you have a mature lib you
| just want to include wholesale in Rust.
|
| But yeah bottom line, nowhere does Rustc "stop" you from
| doing things. Just strongly discourage :)
| trissylegs wrote:
| I supposed that's why they're writing drivers not crypto
| libraries. The sample in the article is Binder. Which is only
| needed for platforms Android supports. Which are all Tier 1 & 2
| Rust targets. (As is MIPS too).
|
| If you wrote a driver for HW that only appears on 1 or 2 CPU
| architectures then targeting is less of an issue. I would not
| be surprised if lots of drivers in Linux only work on x86
| anyway.
| bitwize wrote:
| > It is not fun but frustrating to work in Rust, and contrary
| to C, you are limited by the language/compiler on what you can
| do.
|
| People who have had prior exposure to C tend to find Rust
| frustrating.
|
| People who have not had prior exposure to C tend to find it
| fun, and an average programmer of this sort can fearlessly
| write bare-metal code that beats the code of the best C
| programmers writing in C in safety and rivals it in
| performance.
|
| Systems programming has been fundamentally _changed_ by Rust.
| It 's become as accessible and democratized as web programming,
| no longer the sole province of a cadre of elite C programmers.
| jcranmer wrote:
| Based on Debian's popcon numbers (https://popcon.debian.org/),
| Rust has support for 99.99% of users. The reality is that if
| you're using architectures at that level of reality, no one
| actually supports your architecture, so you're reliant on
| locally patching software and hoping things work.
|
| (Note that MIPS is a Tier 2 support for Rust, which is a
| commitment to keep it building but does not obligate running
| tests for every checkin).
| kmeisthax wrote:
| Indeed. The _vast_ majority of computing environments are
| covered by existing rustc support. However, people in weird
| retrocomputing environments are more or less existentially
| threatened by Rust.
|
| In my personal experience (since I wanted to see how big of a
| problem this is), I looked into bringing up Rust as a cross-
| compiler for Mac OS 9. This requires a compiler that can emit
| PowerPC machine code, as well as a toolchain that can handle
| XCOFF objects and classic Mac OS's strange resource formats
| (if you ever wondered why Win32 has resources, that's why).
| Retro68k provides such a toolchain (albeit GCC based), and I
| wrote a rustc target file to make it spit out XCOFF objects
| in PowerPC format.
|
| Then I got hit with a bunch of llvm assertions about
| unimplemented functionality in it's XCOFF generator and gave
| up.
|
| Less anecdotally, the ArcaOS people (responsible for trying
| to keep IBM's freakshow fork of Windows and DOS alive) and
| TenFourFox both have abandoned attempts to maintain Firefox
| forks for OS/2 and old Mac OS X (respectively), specifically
| because of the Quantum update making Rust a requirement to
| build Firefox.
|
| I heard Rust did merge in a GCC backend, which might help
| some of these retrocomputing projects... but there are
| platforms out there where the primary (or only) development
| environment is a proprietary C compiler. (e.g. Classzilla
| uses Metroworks to provide old Mozilla on Mac OS 9) I'm
| starting to wonder if some kind of "Rust to C" backend might
| be useful for these cases...
|
| Linux also can't abandon hardware support for some of these
| weird environments, either. So until and unless Rust-with-GCC
| can compile on every environment Linux does, we aren't going
| to see anything more than Rust drivers.
| [deleted]
___________________________________________________________________
(page generated 2021-07-24 23:01 UTC)