4 ms·
Sorry, but you're rather sure of yourself when it's not clear whether you understand the constraints kernel writers are operating under. On many platforms simpl
by belovedeagle 9y ago
Sorry, but you're rather sure of yourself when it's not clear whether you understand the constraints kernel writers are operating under. On many platforms simply enumerating valid RAM addresses where a heap may be constructed, let alone mapping them, is going to require considerable effort. It will inevitably be necessary to use memory somewhere off the stack to achieve that effort. Yet it will also be very difficult to write a custom allocator for that environment.
One choice, for example, would be to rely on the bootloader's handling of .bss sections to allocate a temporary 'heap'. Haven't tried it, but it probably gets the job done well enough to bootstrap a real dynamic allocator. The point is, though, you can't just say "throw lazy-static and a custom allocator at the problem". Note, for example, my proposed solution requires writing the custom allocator entirely outside of Rust, since it can't access any Rust statics. It also requires two implementations of the custom allocator - one for bootstrapping, and the other after bootstrapping. These will have to be dynamically selected between at runtime since (AFAIK) Rust is hardly going to support static switching between them. Then you have to consider interoperability between them.
Finally, not all kernel designs are prepared to do any kind of dynamic allocation at all: microkernels which hand all available physical memory to userspace for management there cannot dynamically allocate (except, perhaps, for O(1) of allocation in a small, static heap - but at that point, what's the point?).
- bascule 9y agoYou are making the exact same strawman argument as the post I was responding to. I gave a specific example of how lazy-static solves a specific problem mentioned in the paper, and as far as I can see nothing you have said refutes that. Clearly YMMV as to whether or not you can support a kmalloc()-style API. If you can, allocators will be great for you, and if not they are worthless. I didn't mean to imply Rust has one-size-fits-all solutions to these problems. Rust provides a lot of solutions to various problems, and it's up to you as the Rust developer to figure out which ones are applicable to your problem at hand.
- belovedeagle 9y agoSo what you're saying is, "if your use-case doesn't support kmalloc then shut up and go away, no statics for you!"? That's ridiculous, inappropriate, and generally unhelpful.
- bascule 9y agoNo, again that's a strawman. To explain it for the third time: I was addressing a specific complaint made in the paper and providing a solution. So far I have not seen any counterarguments against this specific solution to this specific problem. Later I pointed out allocators are a great solution if you're able to use them. Again, if you can't, I'm afraid you're out of luck and I apologize this solution doesn't fit your needs. You can, of course, still make statics, you just won't be able to use Box to conveniently allocate buffers in an automatic and type-safe way. Also check out UnsafeCell if you want to assert as the developer on behalf of your program that you're accessing data in a memory safe way.
- dang 9y agoThat's unduly personal and predictably led to worse. Please don't conduct technical arguments this way on HN (or any arguments). We detached this subthread from https://news.ycombinator.com/item?id=14107906 https://news.ycombinator.com/item?id=14107906 and marked it off-topic.