Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I know this is a young project, but right now it looks like a terrible waste of Rust's features. Raw pointers everywhere, most allocations unchecked, and 264 unsafes in just the kernel.

unsafe is a necessary escape hatch, but the temptation to use it to write C-style code is strong.



Hello, I wrote Redox, and I completely agree. I have been doing pretty substantial cleanups in this manner recently. At first, I had to start with pretty nasty code to get things going. Within the last week, I seperated out fundamental applications and moved them to the filesystem. This also meant writing a syscall interface, which is currently compatible with Linux system calls. Unsafe is often necessary in kernel land, and I am always rewriting code to make its use span smaller scopes.


Hello! I think it's possible to encapsulate unsafe pointer operations so they're only required in memory allocation, I/O primitives, and device DMA. I'll open a github issue or two with thoughts.

Out of curiosity, are you modeling this on an existing code base/architecture, or is this a new design?


This is a new design, but the syscall interface is like Linux, the read/write/open/close/ syscalls are the same ABI.

As for unsafe, it would be possible to make much less of the kernel unsafe. The kernel allocation could be exposed in an interface like this:

struct Memory { address: usize }

impl Memory { fn new() -> Option<Memory>; fn realloc(&mut self, size: usize) -> Option<Memory>; fn size(&self) -> usize }

impl Drop for Memory { fn drop(&mut self) }

PIO could be wrapped up MUCH better:

PIO8, PIO16, and PIO32 could handle inb, inw, ind. A lot of my driver bugs have come from using the wrong size!

MMIO could be handled similarly.

The PCI driver could give drivers a limited set of PIO and MMIO structs to operate on


Maybe you could add some constructive criticism in a few GitHub issues? I'd say these kinds of things are easier to fix earlier rather than later.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: