6 ms·

"The only problem is that rust was built with the idea that it will be used with a malloc style memory allocator. This kind of allocator is rather hard to imple

"The only problem is that rust was built with the idea that it will be used with a malloc style memory allocator. This kind of allocator is rather hard to implement using slab allocators since malloc must be able to allocate buffers of any size." ... "About the only somewhat difficult challenge was that I was unable to find any clean way to switch between different virtual terminals. I ended up having to just update a pointer so that the interrupt subsystem could know which TTY to send input to." (discouraged in rust). It's a good exercise to try to take a language with promise and use it for a systems task to understand what's possible. But sometimes some languages need to be systems languages, and others need to be application languages, because there are different assumptions and default cases we want to make easy/possible for developers.

digi_owl 12y ago
Well TTYs are apparently they own kind of hell. We are talking about a system that can trace a lineage back to the Morse telegraph...
- fl0wenol 12y ago
  With bits like schedulers and device drivers in an interrupt-based system a lot of ideas we'd like to about runtime state as modeled by your language of choice (the stack, lexical scope, memory, thread context, reference counts) become exposed and the implementation details have to be known, or you have to be comfortable tuning/self-restricting use of features around such a tricky, dragons-be-here scenario. This isn't a problem specific to TTYs, but indeed they are their own special little hell no matter how you choose to tackle them.
- errordeveloper 12y ago
  I like OSv, just because it doesn't have TTYs.
pcwalton 12y ago
Allocators are being worked on. It's not a fundamental language design issue. It didn't make it for 1.0, but the infrastructure to eventually supporting custom allocators has been part of the design of the standard library for quite a while.
userbinator 11y ago
I ended up having to just update a pointer so that the interrupt subsystem could know which TTY to send input to." (discouraged in rust). Why would that be discouraged, and what would be the "Rust way"? That sounds like the simplest, most straightforward way to do it.
- steveklabnik 11y ago
  You don't _generally_ do arbitrary pointer arithmetic in Rust. You can, with the 'raw pointer' type, but this paper attempted to use all of Rust's higher-level features. Raw pointers need `unsafe` to dereference, and unless you're doing something like this, aren't generally needed, so are 'discouraged' in a certain sense.
- scialex 11y ago
  > what would be the "Rust way"? I'm not sure there is one TBH.

digi_owl 12y ago

Well TTYs are apparently they own kind of hell. We are talking about a system that can trace a lineage back to the Morse telegraph...

fl0wenol 12y ago
With bits like schedulers and device drivers in an interrupt-based system a lot of ideas we'd like to about runtime state as modeled by your language of choice (the stack, lexical scope, memory, thread context, reference counts) become exposed and the implementation details have to be known, or you have to be comfortable tuning/self-restricting use of features around such a tricky, dragons-be-here scenario. This isn't a problem specific to TTYs, but indeed they are their own special little hell no matter how you choose to tackle them.
errordeveloper 12y ago
I like OSv, just because it doesn't have TTYs.

pcwalton 12y ago

Allocators are being worked on. It's not a fundamental language design issue. It didn't make it for 1.0, but the infrastructure to eventually supporting custom allocators has been part of the design of the standard library for quite a while.

userbinator 11y ago

I ended up having to just update a pointer so that the interrupt subsystem could know which TTY to send input to." (discouraged in rust). Why would that be discouraged, and what would be the "Rust way"? That sounds like the simplest, most straightforward way to do it.

steveklabnik 11y ago
You don't _generally_ do arbitrary pointer arithmetic in Rust. You can, with the 'raw pointer' type, but this paper attempted to use all of Rust's higher-level features. Raw pointers need `unsafe` to dereference, and unless you're doing something like this, aren't generally needed, so are 'discouraged' in a certain sense.
scialex 11y ago
> what would be the "Rust way"? I'm not sure there is one TBH.