3 ms·
My current approach to the heap problem (I'm working on a toy Rust kernel) is to compile the allocator portions of the standard library (liballoc) with a config
by krzysz00 11y ago
My current approach to the heap problem (I'm working on a toy Rust kernel) is to compile the allocator portions of the standard library (liballoc) with a configuration flag that makes them use a particular set of external functions as the low-level heap allocation machinery. Then, my kernel provides these functions, and all the nice stuff (Box, Vec, etc.) "just works".
IF you're curious, the relevant code is at https://github.com/krzysz00/rust-kernel/blob/master/kernel/malloc.rs https://github.com/krzysz00/rust-kernel/blob/master/kernel/m... . The functions that start with "rust_" are the allocator interface
- bliti 11y agoVery interesting. Thank you for sharing. Would it be too much to ask for more?
- mastax 11y agoThat's much easier than I thought it was! I'll have to start working on my kernel again.
- krzysz00 11y agoYou can find some more {complex, idiomatic, not terribly hacked together} Rust kernels at https://github.com/thepowersgang/ https://github.com/thepowersgang/ .
- FreeFull 11y agoCouldn't help but notice, F' as u8 is equivalent to b'F' , and ['F' as u8, 'R' as u8, 'E' as u8, 'E' as u8] is equivalent to *b"FREE" which definitely is a lot more concise :). These are called byte string literals. Edit: The dereference is necessary because b"FREE" on its own has the type &[u8; 4].