Why C? I'm just curious if another language can be used. (c++, go, rust).
Here is someone else who has done something similar in Rust, http://jvns.ca/blog/2014/03/12/the-rust-os-story/ (she has other posts on Rust kernel iirc)
Kernel 101 – Let’s write a Kernel
61–70 of 104 posts
Re: Kernel 101 – Let’s write a Kernel
#62If anybody is doing this, let me share some words of advice based on experience. Please use a virtual machine instead of doing this on your primary machine. You eliminate the risk of messing up your machine. Also, if you setup the VM properly, you get a debugger.
[deleted]
Re: Kernel 101 – Let’s write a Kernel
#63I'm not exactly Linus Torvalds but I'm pretty sure a program that prints one line of text is not "a kernel". :)
That's how the Linux kernel started. (technically it was two lines of text printing alternately to prove the scheduler worked, but close enough)
Not that this article isn't cool and valuable, but the fact that it had a scheduler at all puts it light years ahead of this in being-a-kernel.
Re: Kernel 101 – Let’s write a Kernel
#64I'm not exactly Linus Torvalds but I'm pretty sure a program that prints one line of text is not "a kernel". :)
I'm going to give OP the benefit of the doubt on this one. A couple things worth noting, it successfully boots, does not cause a fault of any kind, and is in a position to interact directly with the bare metal. The tools that we use to interact with a *nix system are often just that, bits of code in user-space. This is a kernel-space program. That it does not do any of the memory management or device access yet doesn…
> Maybe implement a game that doesn't have the overhead of an os.
I'm in CMU's operating systems class right now and that was one of our projects (our second). The first was writing a stack-tracing debug library, the third was a user-space thread library built on top of a particular kernel spec, and then the fourth was to build a kernel basically from scratch, using our thread library as a test program.
Here's a link to the spec for the game we built on the bare metal: https://www.cs.cmu.edu/~410/p1/proj1.html
That fourth project, or "p3" as it's known around here, is known to be a killer. It's tough to write a whole kernel in 6 weeks (+ 1 week of break), especially when it's expected to have a full virtual memory system, kernel tasks/threads for concurrent programming, program loading, interrupt handling, etc, even with a partner.
Re: Kernel 101 – Let’s write a Kernel
#65Re: Kernel 101 – Let’s write a Kernel
#66Neat read so far! Not done yet, but I think I've found a small error in kernel.c: the attribute byte of the characters in "my first kernel" should be set to 0x02, not 0x07. edit: I misread. 0x07 is intentional, 0x02 was mentioned as an alternative. Good post!
uaygsfdbzf: your account is marked dead it seems, so most of us can't see what you write. Here's what he posted: Not an error. 0x02 means green character on black background. 0x07 means light grey character on black bg. It's explained with one, and coded with another.
Not dead for me, and I don't have showdead on.
Re: Kernel 101 – Let’s write a Kernel
#67I kinda wish some of the FS utilities were better. Despite FUSE, mounting a block device (like, disk image) as a non-root user is tough, so writing to an image with actual partitions/FS on it is difficult, especially to script, especially if you don't want to sudo in a build script. losetup on a disk image doesn't (to my knowledge) detect partitions… for reasons unknown to me.
Bootsectors are similar. You can't just install grub to a disk image. (You have to losetup it, at the very least, which implies root. Why can't I just install to a file?)
You want a script/build system that allows you, at the very least, to:
1. Code. 2. Run build system/script. 3. Fire up qemu or similar.
You can't be rebooting. Ideally, it'd be great to do this in userspace.
That said, if you're starting out, just do [boot sector] + [kernel] = tada image until you need to do otherwise. (Really, do whatever works and is easy.)
That said, I've found a few somewhat helpful tools.
fuseloop[1] takes a file and offset/size, and exposes a single file. If you have a partitioned disk image, then you can feed it the partition offset, and it gives you back something you can format as an FS. (e.g., you can run ext2fs on.)
Then there's fuse.ext2[2], which mounts an ext2 FS on FUSE, so non-root usable again. Note that I'm linking to my fork of it, since the original didn't build for me, but I didn't write it. (Which I fixed, and sent a pull request, but never heard back.)
Finally — and sorry to peddle my own stuff again — I wrote a Python library for dealing with the MBR.[3] I use it to figure out offsets and sizes in a disk image.
I've had a bit of fun writing a boot loader, and I've managed to get it to load up its stage 2 and switch to 32-bit pmode. Had a fun error where a division instruction was throwing things into a triple fault; see [4] if you want to see how a division instruction can fail without dividing by zero (which was the first thing I checked). The disk layout is currently:
[boot sector] [stage 2] [kernel] [ partitions, FS, real data, etc. ]
[1]: https://github.com/jmattsson/fuseloop
[2]: https://github.com/thanatos/fuse-ext2-fakeFS
[3]: https://github.com/thanatos/pymbr
[4]: http://stackoverflow.com/questions/21212174/why-cant-i-step-...
Re: Kernel 101 – Let’s write a Kernel
#68I just finished an Operating Systems final today and the entire class was conceptual and learning fundamentals, while I craved to get my hands dirty and actually try to make a simple OS.
I'll definitely be playing around with this. Thanks!
Re: Kernel 101 – Let’s write a Kernel
#69This was fantastic. My only question is, how does one gain knowledge of the required x86 hardware specifics he mentions? I don't know where to begin looking to uncover these sorts of things:
- The x86 CPU begins execution at the physical address [0xFFFFFFF0]
- The bootloader loads the kernel at the physical address [0x100000]
- The BIOS copys the contents of the first sector to physical address [0x7c00]
Re: Kernel 101 – Let’s write a Kernel
#70This was fantastic. My only question is, how does one gain knowledge of the required x86 hardware specifics he mentions? I don't know where to begin looking to uncover these sorts of things: - The x86 CPU begins execution at the physical address [0xFFFFFFF0] - The bootloader loads the kernel at the physical address [0x100000] - The BIOS copys the contents of the first sector to physical address [0x7c00] Is there an x…
There is a book called Advanced 80386 programming techniques by Jim Turley - it was referenced in Robert Love's Linux Kernel Development book.
Other resources include http://www.brokenthorn.com/Resources/OSDevIndex.html
There is also the JOS kernel part of an MIT course. There were instruction to build a special version of bochs (pc emulator) and run various kernels you develop in it.