OSDev.org

So... I know most of the regulars on here get a lot of "FIX IT AND HELP!" messages and forum posts. This isn't one of those so don't worry. I have built a couple of small and basic bootloaders to familiarise myself with assembly and NASM (as it seems quite newbie friendly.) I have also written programs in C hosted environments before so I am fairly familiar with the language. I had a look at the bare bones tutorial and the meaty skeleton and have implemented all of the meaty skeleton features into my kernel. So, I know that the C library needs expanding, I need some form of hardware abstraction to allow the kernel (and C library) to use the hardware. I'm using GRUB2 as my bootloader so I don't have to write 2 OS's (Bootloader being another theoretical OS) I was just wondering if anyone would be able to give me helpful pointers as to what I should try and add in before it gets *massively* complicated. Thank you.

A coherent, overall design. If you want to just take the past of least resistance and make a unix clone for the learning experience, that's one way. You could also pick another relatively established design like a microkernel and start figuring out where you want to put all the pieces of your system. Or you could do your own thing and try out something new. Whichever you choose you'll probably need a lot of research into how existing systems work as well as a lot of thinking about the possibilities.

It depends on what motivates you. Some people have no problem studying a lot of theory before they even start the first line of code, and that's great. That's not me, though. I need something working to play with if I want to keep my motivation.

So if you're anything like me, I wouldn't worry too much about the design just yet. Making a good design requires some knowledge, and you get that either by studying a lot of theory or by just doing something. At this point it's about learning how the hardware works and you can do that just fine with a bad design. Of course, you'll have to plan with throwing away or at least rewriting large parts of your first attempt eventually, but then you'll have some practical experience.

The path for someone like me would roughly be implementing some text output, get interrupts working, implement a keyboard driver and then some kind of in-kernel interactive shell (or actually any application: my first kernel just read two numbers from the keyboard and printed the sum). Then multitasking, memory management and userspace tasks - at this point you can start running a real shell outside kernel space. And then just add whatever is needed for new shell commands, it's very individual from this point on. Probably a disk driver (floppy or hard disk) and filesystem will come soon then.

And then you can start worrying about the design and move the keyboard driver out of the kernel if you want a microkernel, etc.

I think you're right Kevin, I do need the code as a base for ideas and learning. I have a backup copy of what I've already done so I can mess around with structure and design without having to start completely from scratch every time. Keyboard driver was my next thought as well as the abstraction into stdio.

Rusko, I was hoping at some point when it's all a bit more "built" to add in compatibility with Linux. One of my first thoughts was simulating or implementing the Linux sys calls in my own kernel but I'd need to verify that it can be done and work out the semantics of it. (Lots more research necessary.)

Regardless of my ideas, thank you for the advice.

TheAlmostGenius wrote:I have a backup copy of what I've already done so I can mess around with structure and design without having to start completely from scratch every time.

I hope you're using some kind of version control? If not, that's the next thing for you to do.

The first thing I do for any non-trivial code is creating a git repository. I don't mind if you prefer a different version control system, but do use one. An OS is a large project and it's not a good idea to try managing it with manual archiving.

Keyboard driver was my next thought as well as the abstraction into stdio.

As long as you know what you want to see next, it's easy: Just do that.

One of my first thoughts was simulating or implementing the Linux sys calls in my own kernel but I'd need to verify that it can be done and work out the semantics of it.

Some basic support is possible and probably not even very hard. Complete support of the whole Linux userspace API is probably too much work for a single person.

I have a temporary SVN system on my development PC but hoping to get it migrated to my server using a different VCS soon. That was the first thing I set-up after the cross-compilation tools. As for the linux support, I was hoping to put in enough to get certain linux utilities running on my OS (GCC and Binutils would allow for self replication...) Maybe the command line utilities would be far enough as I'm probably not going to use GNOME as my GUI. I could imagine that needing a LOT of work. I was mostly looking to see if there was anything else that would be good to put in "before it's too late..." maybe something that's not so obvious.

If that's your goal, I'd recommend you to ensure sure compatibility on the libc level (by implementing POSIX interfaces) rather than on the syscall level. Then your OS will look like any random Unix clone. The programs that you're interested in are designed to work on many of the existing Unices and therefore already support many libcs on the source code level and accommodate many possible differences between them. If your libc looks reasonably POSIX, the configure script should mostly figure out what to do with it, so you can just build a native version for your OS. (And the remaining part will result in compile errors, which you address by extending/fixing your libc.)

I suppose the first thing is to decide what you want your operating system to do. Coming up with something which is:

a.) New, and
b.) Makes some sort of sense

is probably a lot easier said than done. But, if you can do it, and you have some experience of writing moderately large programs, then you can start figuring out how the thing you have decided upon can be accomplished - at least in outline. The alternative to finding something new is to write yet another clone of Unix, which, of course, requires little imagination.

My first goal is to make a stable system that I can eventually use as a replacement for Linux on my PC. (Without being a *nix deriative)
Programmed using as much C as possible.
I know that in order to put some of the GNU tools on my non-unix kernel I'd need a way of using the POSIX library. Would it be better to implement POSIX as a separate library alongside the C library that can be used only by the programs that need it? (Rather than muddying the Standard C with POSIX headers(and don't the POSIX headers require POSIX compatible system calls))
This is my current understanding of how these 2 work. ANSI C is a library that makes no massive assumptions and can easily be ported between x86 and x86_64 using preprocessor directives. POSIX was a separate C standard that makes more assumptions and requires more kernel support. ANSI is used to write the first parts of the system in C and add the POSIX compatibility into the kernel as extra real syscalls (Making the OS POSIX compatible) Then the POSIX compatible program calls the POSIX library to access the function calls required. ANSI C however would only require the C library be present as the syscalls should already be in place with the kernel having been written in ANSI C and not quite being the same kind either. So wouldn't adding the calls for POSIX basically make my kernel another *nix clone anyway considering it was basically designed around *nix style OSes.

TheAlmostGenius wrote:ANSI C is a library that makes no massive assumptions and can easily be ported between x86 and x86_64 using preprocessor directives. POSIX was a separate C standard that makes more assumptions and requires more kernel support. ANSI is used to write the first parts of the system in C and add the POSIX compatibility into the kernel as extra real syscalls

That's not how it works in practice. POSIX tends to be lower level than the standard C library. So usually a *nix kernel implements the syscalls required for the POSIX interfaces and the function of the C standard library are implemented on top of this (e.g. fread() from stdio.h will call POSIX read() for the actual reading and just implement some buffering mechanism in addition).

So wouldn't adding the calls for POSIX basically make my kernel another *nix clone anyway considering it was basically designed around *nix style OSes.

Yes, if your kernel interface is made for POSIX, I'd call it a *nix.

What you can try to do is creating your own native API that looks how you want it to look and then implementing POSIX on top of that, as something like a compatibility layer, which just implements POSIX functions as wrappers around your native interface. If you want to do this, though, be aware that POSIX contains a few concepts that are quite hard to map to different concepts. One of them is the separation of fork/exec, which allows running some code between them, and the whole file descriptor inheritance model. It's a powerful concept, but also one that takes a big influence on your design.

So if I want the easiest way, I'd have to write a POSIX compliant kernel and then implement C library, to create a *nix clone or create my own kernel but spend extra time adding in compatibility for the "extra-kernel" POSIX library. (So that could be implemented like the libraries used in an exokernel. So either in userspace or between kernel and userspace.)