2 ms·
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
by jackpot51 11y ago
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.
- acconsta 11y agoHello! 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?
- jackpot51 11y agoThis 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