Hacker News Reader

Comment by vibrantrida | Hacker News Reader

There are two Japanese operating system development books I wish have English translations because they take you as far as getting a graphical environment with windows working [0], one of the books is even a 30-days challenge of sort [1].

Here is someone's take on MikanOS [0] https://github.com/uchan-nos/mikanos

And another one on 30-days Homemade OS [1] https://github.com/kamaboko123/30daysOS

An attempt to translate "30-days Homemade OS" [1] to English but it didn't get far https://github.com/handmade-osdev/os-in-30-days

I do not know of any English book nor article that go this far, except Fusion but the graphical environment chapter is not done yet [2]

[0] https://www.amazon.co.jp/dp/4839975868 - MikanOS

[1] https://www.amazon.co.jp/dp/B00IR1HYI0 - 30-days Homemade OS

[2] https://0xc0ffee.netlify.app/osdev/ - Fusion, an OS made in Nim

View on HN

Fusion author here. I haven't abandoned the project, and I do plan to complete it, including a graphics subsystem and a network stack. I'm currently trying to crack a tough nut, which is efficient zero-copy IPC using message passing over channels with a shared heap. This is a fundamental piece that will be used to communicate between different components (both within the kernel and across kernel-user space). Once I have a proper implementation, I expect the pace to pick up.

And of course I will document everything as I make more progress.

Are you trying to do this message passing using Nim channels ? For my use-cases, i always had to resort to just passing `pointers`, to prevent any copying, most of time i just divide the problem to use independent memory locations to write to avoid using locks, but that is not general pattern for sure. For read only purposes i just use `cursor` while casting to appropriate type. If you find a useful pattern, please share.

No. Nim channels are for inter-thread communication within the same process, and they perform a deep-copy of messages. Fusion channels are a different beast. They're kernel objects that require syscalls to create/open/send/recv/close. In order to achieve zero-copy, the channel heap needs to be in user-space, but managed by the kernel. It's kind of similar to shared memory on POSIX, but has message passing semantics, rather than arbitrary read/write from/to shared memory. And since Fusion is a single address space operating system, I have the luxury of passing pointers (to data on the channel heap) directly between tasks without resorting to (de)serialization. Protection is achieved through page table mappings, where e.g. the sender would have read/write access to the channel heap, but the receiver has read-only access to the same memory.

As for your case, I understand the need to avoid locks. In my case, the channel is implemented as a queue of messages, which is implicitly synchronized between tasks. Currently it's implemented using a blocking queue, since I want to put senders/receivers to sleep when the queue is full/empty, respectively. The API does support a no-wait option, but I'm not currently using it.

There will be a lot to write about once I'm past this point :)

Thanks for explaining it, given you are writing it from scratch it gives you a lot of control in modelling a particular feature!

I did bookmark this project a few months ago but couldn't spend time to understand more about it. I wasn't aware of documentation, which should now make it easy to start with. Thanks for putting a lot of work in documentation!

Reply on news.ycombinator.com