On 12/27/13 8:18 PM, Daniel Micay wrote:
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.
I'd like to make that stuff either moved out into a separate library or
discardable.
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...
This isn't always a problem. Check out Apple's `OSDictionary`, for
example, which is designed for use in kernel space and has the same
restrictions:
http://www.opensource.apple.com/source/xnu/xnu-792.13.8/libkern/c++/OSDictionary.cpp
https://developer.apple.com/librarY/mac/documentation/Kernel/Reference/OSDictionary_reference/translated_content/OSDictionary.html
(It's even reference counted with RTTI and COM-like system! In kernel
space!)
But, in any case, I see no reason why we can't have allocator support in
`libstd`'s containers. Hiding the extra allocator type parameter can be
done with a typedef and some compiler/language work to make that
palatable. There should be an absolute minimum number of containers in
`libstd` in the first place, so I don't see the implementation burden as
insurmountably high.
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.
Then let's get bugs on file and fix them upstream in libstd.
Inefficiency in userspace is just as bad as inefficiency in kernel space.
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.
I share some skepticism about the usability of tasking in kernel space
for high-performance kernels. However, some embedded apps that run in
ring 0 for efficiency/simplicity reasons (e.g. console games) may still
want a task system.
Patrick
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
