On 12/27/2013 09:09 PM, Patrick Walton wrote:
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.
I think we really are close to agreement on the above.
Tasks remain useful as a unit of resource management, independently
of threads or concurrency. Kernel i/o differs, but int->ASCII is
the same as in user space. Logging in kernels is often the only
way to locate bugs, and it differs in initialization, but not in
usage. Memory management in the Linux kernel uses different allocation
methods, but makes very heavy use of (manual!) reference-counted
garbage collection.
Partitioning between core-language and supplementary libraries by
general category would be a mistake. Usually the apparatus that
enforces usage conventions should be in the core, for interoperability,
but embodiments of the conventions (e.g. specific data structures,
spawn() methods, allocators) not.
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.
They are trivial to implement given a design, but a good design is
arrived at only through long and difficult evolution. That makes it
especially worth exposing in the core library, and making user space
analogs match.
Nathan Myers
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
