OSDev.org

As a third-year college student, I embarked on a journey to learn OS development and low-level programming. Initially enticed by a video series titled 'Write Your Own Operating System,' I dove headfirst into this complex field without a solid foundation of knowledge. Now, after seven months of development, I find myself at a crossroads. While I recognize the importance of starting with smaller, more manageable projects, I've invested significant time into this endeavor, hoping to present it as my finishing project in college. However, I feel lost and uncertain about the next steps. I'm open to any advice or suggestions to improve my project and would greatly appreciate any insights. Thank you, and have a nice day.

https://github.com/eraykaradag/CernOS

Sounds like my life story! I spent so many years taking on projects too big, though I mostly got stuck at the design phase. My ideas were just too big for the knowledge I had.

Hmm... I don't know what's needed for your finishing project. Would it be good enough to write up why certain choices in your OS were bad, and what would be better? Though I suppose it would be better if you could both make those explanations and demonstrate some better choices in your OS.

How much time do you have? One dev went from nothing to a working GUI in 5 months, but he was, temporarily, a hermit. He chose to get away from everything by living in a cabin in the woods with nothing but nature and computers for company. You may not be a hermit, but I think you have an advantage over most hobbyists: you can use some of your school time. Having been on this board for a few years, I've noticed that students whose OS is their school project make progress much faster than the norm.

I'll leave to others advice on what choices would make the best use of the time you have. I've been interested in OS dev for a long time, but don't have practical experience. I started an OS last week, choosing to make a microkernel because I felt I wouldn't need to design module loading and in-kernel APIs, only program loading and IPC, but immediately ran into the chicken-and-egg problem of how to boot a kernel which can't do anything for itself. I've traded one design issue for another, though I think I've picked the easier design for the long run.

I have a whole year to develop the project. I just want to create a simple, command-based operating system so I can demonstrate something. I've implemented many parts, but they aren't doing much because they work separately. I want to pull everything together.

OS development is very open-ended. As more of your OS comes together, you have more opportunities to choose which part to build next instead of following a step-by-step guide.

Speaking of guides, those write-your-own-OS tutorials are usually written by beginners, and thus full of beginner mistakes. At some point, you may want to go back and fix common tutorial mistakes like not using a cross-compiler or relying on interrupts to switch tasks.


That usually happens when you run programs on your OS. Maybe that's what you should aim for.

Yeah you are right it's open ended but i don't even know how to find the end. I am doing this project to learn i have no other purpose to do it so i don't know what I want to do with this OS.

It sounds as if you haven’t really thought what it is that you want to achieve. Coding is the least important part of the software development process. First you need to plan exactly what you want your software to do.

What do you think an OS should do? First be clear in your mind what you are trying to produce. Perhaps you need to read some general texts on operating systems before proceeding.

I don't think anybody would be able to plan an OS project in advance. For one, you don't want the very complex interfaces that a more competent OS has to start with. Rather it's more convinient to start with important pieces and then gradually tie them together. This means there will be changes as you merge stuff, maybe some pieces need larger rewrites, but I think successful OS developers can handle this without "starting from scratch".

I’m not saying that you have to plan the detail in advance. But unless someone implementing a software project has a clear view of what that software should do (what, not how) the project is very likely to be a failure.

It doesn’t seem to me that this young person knows what they want the software to do. But perhaps I have misunderstood the question.

Ayup. I've failed several times at planning everything in advance. When I instead decided to just code a traditional native Forth, I didn't have much motivation. (Also, Forth is not exactly easy.) Now, my goals are better balanced; things I can build on but which don't seem too hard. My highest goal at the moment is simple message-passing IPC.


Would they work together if you could pipe the output of one into another? Or if you redirected the output of one to a file, and then used the file as input to another? Redirection and pipes are features in themselves; you could work on them. I'm sure there are several different ways to implement redirection depending on how your programs get standard input and output.

If pipes aren't the right solution, then I guess you need some sort of IPC. I'd start with message passing, though I guess some sort of channel would be good too. Shared memory requires coordination and locks, so it's not so easy to use.

Yeah, there are lots of things missing in the project, like message passing. I think at first, I just want an OS that has a text editor and maybe a compiler in the future. Is that harder than I thought? I have no idea about choosing an OS system design for this kind of purpose, maybe because of a lack of theoretical knowledge. My professor at college recommended NachOS and PintOS so I can easily understand the concepts. Should I look for those kinds of systems to learn more or just keep diving into this project and learning by practicing.

Is it bad that my mind immediately went to "try emacs, and then try porting a good editor to it"?
Ah, choice paralysis. In this case you pick what your gut tells you to and continue on until something tells you to stop. For the question of how to do IPC, I will say that shared memory and locking are going to be primitives you will very likely use to implement any of the other options eekee has mentioned. Like pipes, that's just message buffers and semaphores, only the message buffers are hidden from view through the syscall interface. Message passing is just pipes with more structure.

For the goal you mentioned earlier, it is probably a good idea to use a tried and tested method. And Unix has been making good use of command lines and pipes for half a century now, and the idea has found its way into most other operating systems, so there must be something to it.

It will very much depend on your interests in OS development. Personally, my interests are:

• Page based memory management and address space isolation. This is the most portable means of isolating process address spaces, instead of for example hardware segmentation (a-la x86).
• Multi-threading.
• Multi-processing.

So my initial goals were to see how easy it is to implement paged address spaces with copy on write sharing.

So I'm probably a Lino_Commando aiming for Stan_Dard (I want a POSIX like system.)

Based on that, I started with the Meaty_Skeleton, and from there, started with simple threading and task switching, then added page based address spaces, then added multiple address spaces (with a process abstraction), then added user space.

At this point, I needed something to actually load binaries from of course, so I did a simple ustar based filesystem driver to mount as the root filesystem, which used a grub loaded tar file as a ramdisk. Thus began my VFS. It was also at this point that I made my paging demand loading, the page fault handler interacting with the VFS on demand to load pages and handle copy on write.

Once I'd made it to user space, it was then a question of porting a libc (currently using PDCLIB, but looking at newlib) and getting some simple user processes up and running. fork/exec allowed me to port a simple shell and run static binary commands.

Along this way, I developed whatever tools/code I needed. I found that I was doing a lot of map like work (key/value lookups), so my primary data structure is a key/value map, with various implementations to cater for different use cases.

I started my kernel heap allocator as a pretty standard slab allocator, but noticed how trivially easy this made it to go from a pointer to the allocation details, and built on top of that a simple mark/sweep garbage collector.

But, if it's any consolation, getting lost is probably very typical. I got lost several times, especially implementing complex things like a USB core.

Yup, and if your gut is as confused as your head, list a few options and pick one at random. If it's hard to think of options, try reading random wiki pages, (the wiki has a random page link under Navigation,) or read these forums. The latter is time-consuming, but you can get ideas and inspiration from the things people are working on. I'm always doing something creative, and I've found that whatever kind of thing I'm making, the best way to get inspiration is to read a lot. Videos may help too.




emacs is an os!

Thank you for the advice, but I'm still struggling to find a way forward. It would be helpful to have someone guide me so I can learn more, especially since I'm at the beginning of this field and can't decide what to do next. Thank you all for your kindness, and I hope you have a nice day.

Hi Xodein.

I had a look at your code and it seems that at this point in time you've basically just followed along with the tutorial videos and reproduced exactly what the host did, is that a fair assessment? There's nothing inherently wrong with this as a starting point, but the problem you're now encountering is to be expected. Up until this point someone else was making all the design decisions for you, now you need to start making decisions for yourself, after all, making your own design decisions is what makes it your OS.

Since you have a goal in mind already - present this as your finishing project - I would suggest that your first step is to decide what the "Minimum Viable Product (MVP)" is. What is the least amount of stuff you'd be happy to present in a year's time (I don't know what your collage expects from you but I assume you'd want to finish a few months early to give yourself time to write supporting documentation about your process and what you learned). Once you have an idea of a MVP you can work backwards to find what you have to do first to enable it - for example if you want to write and compile code you need to load and save files, launch programs, you need a text editor and a compiler which will need to be able to allocate memory and interact with the file system from user mode which will require system calls.

Once you know what you need to do you have to start figuring out how, do you want to port existing open source programs to your OS or do you want to write all your own programs, do you want users to interact with a GUI or a command line, will you create a new API from scratch or will you implement an existing API - like POSIX. The best answers may depend on what your MVP is, usually there will be trade-offs and some decisions effect others, for example it will be easier to port programs designed for Linux if you implement a subset of the POSIX standard, but if you write your own programs you can design them around a minimal API which will be less work to implement but you will need to figure out it's design.

If you don't start making these kinds of decisions you'll hit this point of not knowing what to do over and over again, so start thinking about it. All that said though, if I were in your position, I'd try to figure out:
1. How to run a task that actually does something - invoke a syscall for example
2. How to run a task with it's own memory
2b. How to get that task to run in user mode (if you want to actually protect processes from each other)
3. How to load an executable file from disk and launch it as a user application
To me, these are the things a general purpose OS must be able to do to be an OS and not just a program running on bare metal.

Hope this helps, do be aware though that what you've done so far will have been very easy compared to what you're looking at doing now.
The training wheels are off and you're in the deep end.

Edit: Oh yes, and make sure you take advantage of the OSDev Wiki, it is far and away the best single resource on OS development. https://wiki.osdev.org/Expanded_Main_Page