On Fri, Dec 27, 2013 at 10:10 PM, Nathan Myers <n...@cantrip.org> wrote: > On 12/27/2013 01:35 PM, Patrick Walton wrote: >> >> On 12/27/13 1:34 PM, Daniel Micay wrote: >>> >>> Rust tasks and channels don't work in a freestanding environment. >>> Unbounded allocation is *definitely* not suitable for a kernel >>> though... even a large bounded channel would be unsuitable. The world >>> of small stacks and interrupts is quite different than what the >>> standard library is written for. >> >> >> I think the standard library should get there over time though. > > > Possibly the best measure of a language's power is how well it enables > writing generally useful libraries. How much of the standard library > older languages would have had to build in is an objective measure of > success. While important parts of the runtime will be re-implemented > for a kernel setting, kernel coders will need many of the powerful > standard-library features.
Most of the standard library isn't appropriate for a kernel. The support for concurrency (threads/tasks, mutexes, condition variables, blocking channels), floating point math, input/output, failure, multi-processing, logging and garbage collection isn't going to work. The containers in the standard library are quite inappropriate for most kernels since they're based on eagerly allocated vectors prone to fragmenting memory. It also has no support for anything but a hard-wired global allocator based on the malloc/free API... Iterators, atomics, Option and low-level memory/pointer functions are useful, but it's also trivial to re-implement and the standard library doesn't do it particularly well in the first place. > This argues for including those standard-library features that mean > the same everywhere in the "freestanding" language definition. In > kernel code, tasks and channels might be created differently, but > used identically. I don't think the same concurrency concepts will be appropriate in a kernel. Interrupts are a different world than blocking on system calls and you have to be really careful about interactions with userspace code. _______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
