jamesmunns

Doing embedded stuff

Be nice, work hard. Build tools, tell stories. Start five year fights. Kein Ort für Nazis.


A list of all the other services I'm on around the internet


Posts with code highlighted with codehost by @wavebeem.


All posts licensed under CC-BY-SA 4.0, unless otherwise stated.


Talking with @eliza, I realized that my "everything is a driver" plan is generally good, but left me with a totally blank slate of what the kernel needed to draw "the rest of the owl". Unlike MnemOS v0.1, in v0.2 will have a functional boot console, and these are the parts that I think are the minimum set of useful parts that are needed to get it up and running.

This'll also serve to kick the tires of some of the message passing plans purely in kernel space, before re-expanding that back out to userspace with one or more programs.

In this diagram, I have these drivers classified into two groups: Tier One and Tier Two.

In my head, Tier One drivers will be the ones that touch "real hardware" and are platform or device specific. In this case, they'll be simulator specific. Tier Two drivers will be a little higher level, and should be portable across any platform. Rather than having a specific HAL, or Hardware Abstraction Layer, you'll just need to implement the necessary Tier One drivers when porting MnemOS to a new platform.

This also introduces the concept of a BBQueue as a possibility for driver-to-driver communication, but since SO many drivers end up being primarily stream or variable size frame oriented, AND it is already a fundamental part of my ABI for the userspace to kernelspace communication, it seems like a no-brainer to include it.


You must log in to comment.