8 ms·

Having written a lot of driver/kernel code and also dabbled in Rust, I have a hard time seeing anything that Rust can't do in this regard. All of the memory ma

by daeken 11y ago

Having written a lot of driver/kernel code and also dabbled in Rust, I have a hard time seeing anything that Rust can't do in this regard. All of the memory manipulation you will typically do is doable in Rust, though you will certainly lose some of the safety if you're bouncing things between types. The only real limitation you'll have is the inability (AFAIK) to do inline assembly. There'd be no need to rewrite anything to work with Rust; the binaries emitted by the compiler should be just fine, assuming ABI compatibility. Maybe some changes to the way things are linked?

foogered 11y ago
You should be able to use inline assembly in rust-nightly: https://doc.rust-lang.org/nightly/book/inline-assembly.html https://doc.rust-lang.org/nightly/book/inline-assembly.html
- daeken 11y ago
  Awesome, thanks. I knew it was missing last time I checked, but I should never assume with such active development going on!
  - spoiler 11y ago
    cc: @foogered This is what's been so off-putting about Rust, to be honest. "I should never assume" is precisely what bothered me. I loved Rust at first, but it required so much maintenance with its constant changes between versions, that I stated to dislike it. I didn't have much time (and I enjoy learning new languages), but when I had to virtually unlearn something just learned the previous day, it became frustrating after a few iterations. A colleague at work once sneered at me when I suggested I could do my next [internal] project in Rust; I didn't end up using Rust, because I got self-conscious about the idea, and kinda got scared that I'll have to do much, much more work simply because completely valid code would not work in a few days. That feeling is kinda stuck with me to this very day, even though Rust wasn't a stable release back then, and now is. Not to mention, there's people I've talked to about Rust who still feel like Rust isn't mature and never will be—simply because of it's "reputation." [1]: They were referring to how dramatically and chaotically it changed before the first stable release.
    - mathetic 11y ago
      >> They were referring to how dramatically and chaotically it changed before the first stable release. Exactly.
    - pcwalton 11y ago
      What would you preferred Rust have done to avoid this "reputation"? I mean, as far as I can see, the options were "develop Rust in secret" or "make a language much less suited to this domain".
      - mcguire 11y ago
        It's kinda bad, but the other options are worse. What're ya gonna do? (Now, could we do something about the fair-sized chunks of the standard library that are marked "unstable"? I'd be happy with a compiler flag to turn that error into a warning....)
        heinrich5991 11y ago
        There is an option, use the nightly compiler.
      - plesner 11y ago
        I wonder how many of the features in Rust that have changed were designed with that possibility in mind? And if not, whether it would have made any difference if they had been?
        steveklabnik 11y ago
        As a very drastic example, the runtime was only actually removed six months ago. If we still had it, our 'embedding Rust in other languages' story would be significantly worse, and the kinds of things being discussed in this thread wouldn't have been possible.
        pcwalton 11y ago
        The goals of Rust have not really changed since its development. The fact is that (in particular) a region and lifetime system are hard. We were doing research. Research usually requires many attempts to solve a problem.
  - steveklabnik 11y ago
    Inline assembly landed in Rust 0.6, April 2013, so if you haven't checked it out since then, there's a _lot_ of new/different stuff :) We've been discussing stabilizing these kinds of low-level features: no_std is first up. We're not 100% sure inline asm is worth it, as you can always link directly to something that's just written in assembly, but we'll see.
    - daeken 11y ago
      I guess my mental estimate of last having looked "about 6 months ago" was off by a little bit. I think this weekend might be dedicated to writing a Rust kernel. Thanks for your hard work!
      - steveklabnik 11y ago
        No problem. Like I said, we're very interested in making this use-case better, so please file any odd things that crop up. Oh, and there's #rust-osdev on mozilla's IRC where friendly people idle.
    - mattst88 11y ago
      I suspect that the overwhelming majority of cases that warrant inline assembly would not benefit if it was instead a function call out to something you've linked in. That is, most inline assembly is a small snippet of optimized code that necessarily exists in the function you're optimizing.
      - pjmlp 11y ago
        That is why naked and inline exist for.
        daeken 11y ago
        Inline from C libraries won't -- as far as I'm aware -- inline into a Rust function. Inline is a compile-time hint, not a link-time behavior. In theory this could be changed in LLVM, but it seems really unlikely to me. The function exposed from C (with the inline asm) can be naked, though, assuming you are hygienic.
vardump 11y ago
Hmm... Because 32-bit Windows IRQ handler doesn't save FPU/SIMD state, Rust also needs to have ability to suppress any FPU/SIMD output, when generating code to run under 32-bit Windows kernel at DIRQL (= interrupt handler). Otherwise the mayhem in userland will be rather interesting, usermode thread SIMD state gets corrupted. It'd definitely be tricky to use Rust for kernel drivers, but still so tempting!
- daeken 11y ago
  Hm, I bet there's a flag to disable SIMD entirely (not really important here), and maybe even enable softfp if you use any floats in your code (or libraries, by extension). That'd be interesting to hack in, if it's not already there.
  - rkangel 11y ago
    I've written C almost every day at work for ~7 years, and I have maybe written the keyword 'float' half a dozen times. I do embedded and systems development - you never need floating point in that sort of environment. It's only when you get into application domains that you need it.
    - stephencanon 11y ago
      There are a number of architectures where you leave half of the performance of little things like memset and memcpy on the table without SIMD. as a footnote: everytime in my career that someone has said "you never need floating point in X [kernel/network stack/some embedded thing/boot/whatever]," they've come back within a year to ask for my help with floating point library routines for X. So now you've cursed yourself =)
    - com2kid 11y ago
      As an embedded developer let me say that the Cortex M4s with FPUs are worth their weight in gold for saving me from debugging fixed point libraries.
      - 11y ago
monocasa 11y ago
Last time I checked, Rust wasn't great for intrusive data structures, as well as non-tree graphs. Is this better now?
- aidenn0 11y ago
  I'm not sure what you mean by "intrusive data structures" but as far as non-tree graphs, it's only as bad as any other non-managed runtime.
  - monocasa 11y ago
    By intrusive data structures, I mean data structures where the per node metadata is stored within the struct of the data rather than externally. Linux's list_head is a good example of this. Having one less pointer indirection can make it a bit more cache friendly. And yes, Rust can handle non tree graphs as well as any other unmanaged languages, but the heavy use of 'unsafe' makes me feel icky. : )
    - pcwalton 11y ago
      You might be interested in this library: https://github.com/dschatzberg/intrusive https://github.com/dschatzberg/intrusive

by daeken 11y ago

foogered 11y ago

You should be able to use inline assembly in rust-nightly: https://doc.rust-lang.org/nightly/book/inline-assembly.html https://doc.rust-lang.org/nightly/book/inline-assembly.html

daeken 11y ago
Awesome, thanks. I knew it was missing last time I checked, but I should never assume with such active development going on!
- spoiler 11y ago
  cc: @foogered This is what's been so off-putting about Rust, to be honest. "I should never assume" is precisely what bothered me. I loved Rust at first, but it required so much maintenance with its constant changes between versions, that I stated to dislike it. I didn't have much time (and I enjoy learning new languages), but when I had to virtually unlearn something just learned the previous day, it became frustrating after a few iterations. A colleague at work once sneered at me when I suggested I could do my next [internal] project in Rust; I didn't end up using Rust, because I got self-conscious about the idea, and kinda got scared that I'll have to do much, much more work simply because completely valid code would not work in a few days. That feeling is kinda stuck with me to this very day, even though Rust wasn't a stable release back then, and now is. Not to mention, there's people I've talked to about Rust who still feel like Rust isn't mature and never will be—simply because of it's "reputation." [1]: They were referring to how dramatically and chaotically it changed before the first stable release.
  - mathetic 11y ago
    >> They were referring to how dramatically and chaotically it changed before the first stable release. Exactly.
  - pcwalton 11y ago
    What would you preferred Rust have done to avoid this "reputation"? I mean, as far as I can see, the options were "develop Rust in secret" or "make a language much less suited to this domain".
    - mcguire 11y ago
      It's kinda bad, but the other options are worse. What're ya gonna do? (Now, could we do something about the fair-sized chunks of the standard library that are marked "unstable"? I'd be happy with a compiler flag to turn that error into a warning....)
      - heinrich5991 11y ago
        There is an option, use the nightly compiler.
    - plesner 11y ago
      I wonder how many of the features in Rust that have changed were designed with that possibility in mind? And if not, whether it would have made any difference if they had been?
      - steveklabnik 11y ago
        As a very drastic example, the runtime was only actually removed six months ago. If we still had it, our 'embedding Rust in other languages' story would be significantly worse, and the kinds of things being discussed in this thread wouldn't have been possible.
      - pcwalton 11y ago
        The goals of Rust have not really changed since its development. The fact is that (in particular) a region and lifetime system are hard. We were doing research. Research usually requires many attempts to solve a problem.
- steveklabnik 11y ago
  Inline assembly landed in Rust 0.6, April 2013, so if you haven't checked it out since then, there's a _lot_ of new/different stuff :) We've been discussing stabilizing these kinds of low-level features: no_std is first up. We're not 100% sure inline asm is worth it, as you can always link directly to something that's just written in assembly, but we'll see.
  - daeken 11y ago
    I guess my mental estimate of last having looked "about 6 months ago" was off by a little bit. I think this weekend might be dedicated to writing a Rust kernel. Thanks for your hard work!
    - steveklabnik 11y ago
      No problem. Like I said, we're very interested in making this use-case better, so please file any odd things that crop up. Oh, and there's #rust-osdev on mozilla's IRC where friendly people idle.
  - mattst88 11y ago
    I suspect that the overwhelming majority of cases that warrant inline assembly would not benefit if it was instead a function call out to something you've linked in. That is, most inline assembly is a small snippet of optimized code that necessarily exists in the function you're optimizing.
    - pjmlp 11y ago
      That is why naked and inline exist for.
      - daeken 11y ago
        Inline from C libraries won't -- as far as I'm aware -- inline into a Rust function. Inline is a compile-time hint, not a link-time behavior. In theory this could be changed in LLVM, but it seems really unlikely to me. The function exposed from C (with the inline asm) can be naked, though, assuming you are hygienic.

vardump 11y ago

Hmm... Because 32-bit Windows IRQ handler doesn't save FPU/SIMD state, Rust also needs to have ability to suppress any FPU/SIMD output, when generating code to run under 32-bit Windows kernel at DIRQL (= interrupt handler). Otherwise the mayhem in userland will be rather interesting, usermode thread SIMD state gets corrupted. It'd definitely be tricky to use Rust for kernel drivers, but still so tempting!

daeken 11y ago
Hm, I bet there's a flag to disable SIMD entirely (not really important here), and maybe even enable softfp if you use any floats in your code (or libraries, by extension). That'd be interesting to hack in, if it's not already there.
- rkangel 11y ago
  I've written C almost every day at work for ~7 years, and I have maybe written the keyword 'float' half a dozen times. I do embedded and systems development - you never need floating point in that sort of environment. It's only when you get into application domains that you need it.
  - stephencanon 11y ago
    There are a number of architectures where you leave half of the performance of little things like memset and memcpy on the table without SIMD. as a footnote: everytime in my career that someone has said "you never need floating point in X [kernel/network stack/some embedded thing/boot/whatever]," they've come back within a year to ask for my help with floating point library routines for X. So now you've cursed yourself =)
  - com2kid 11y ago
    As an embedded developer let me say that the Cortex M4s with FPUs are worth their weight in gold for saving me from debugging fixed point libraries.
    - 11y ago

monocasa 11y ago

Last time I checked, Rust wasn't great for intrusive data structures, as well as non-tree graphs. Is this better now?

aidenn0 11y ago
I'm not sure what you mean by "intrusive data structures" but as far as non-tree graphs, it's only as bad as any other non-managed runtime.
- monocasa 11y ago
  By intrusive data structures, I mean data structures where the per node metadata is stored within the struct of the data rather than externally. Linux's list_head is a good example of this. Having one less pointer indirection can make it a bit more cache friendly. And yes, Rust can handle non tree graphs as well as any other unmanaged languages, but the heavy use of 'unsafe' makes me feel icky. : )
  - pcwalton 11y ago
    You might be interested in this library: https://github.com/dschatzberg/intrusive https://github.com/dschatzberg/intrusive