Live data from Hacker News

Kernel 101 – Let’s write a Kernel

arjunsreedharan.org

91–100 of 104 posts

Re: Kernel 101 – Let’s write a Kernel

#91
post #12

Earlier quoted context omitted.

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…

Reminds me of the old "booter" games on the PC that used their own kernel instead of MS DOS [1] It would be fun to see how far one could go with modern hardware. Writing your own driver for a modern graphics card sounds absolutely terrifying (and fun). [1] http://en.wikipedia.org/wiki/PC_booter

This one was awesome: http://en.wikipedia.org/wiki/Buck_Rogers:_Planet_of_Zoom#Pla...

CGA graphics(!), and pushed the monophonic speaker on a basic XT further than anything I'd seen at the time.

Unplayable on "turbo" mode :-)

Re: Kernel 101 – Let’s write a Kernel

#92
post #87
post #79

Earlier quoted context omitted.

> Can anyone give me an idea how much different this would be for 64bit? Do I just change the nasm directive to `bits 64`? A lot different. You can see the boot code of my x86_64 hobby kernel project [1]. The reason is that GRUB/Multiboot protocol is actually doing most of the machine initialization, but it can only set up 32 bit mode. 64 bit mode is missing partly because standardizing the Multiboot protocol is drag…

This makes me really sad. 32bit mode x86 assembly is such a mess compared to amd64 -- I guess it's a good excuse to work with qemu and arm, if nothing else ;-)

On the topic of ARM, does anybody know of a similar example like this for ARM? One that just shows you how to pass control to C and do some basic I/O?

Re: Kernel 101 – Let’s write a Kernel

#93
post #82

I got this running on qemu by cannibalizing a tiny bit of code from xv6 ( http://pdos.csail.mit.edu/6.828/2012/xv6.html ) to replace the GRUB dependency. After cloning and building mkernel according to its instructions: $ git clone git://pdos.csail.mit.edu/xv6/xv6.git $ cd xv6 $ make Now you should be able to run xv6 by itself: $ path-to-qemu/x86_64-softmmu/qemu-system-x86_64 -serial mon:stdio -hdb fs.img xv6.img -m…

> I got this running on qemu by cannibalizing a tiny bit of code from xv6 to replace the GRUB dependency. This thing doesn't depend on GRUB, per se. It requires a multiboot protocol compliant bootloader, and QEMU and Bochs emulator have one built-in. All you need to do is: qemu-system-i386 -kernel kernel This was mentioned in the last lines of the OP, perhaps they were added after you read it.

Ah. Thanks! Yeah, I'd emailed the author with my comment.

Re: Kernel 101 – Let’s write a Kernel

#94
post #89
post #84

Earlier quoted context omitted.

I highly recommend http://www.hokstad.com/compiler/ ; it talks about writing a compiler in a way that makes sense to me - writing it the way you write any other program, rather than throwing you straight in with lexers and parsers and never justifying why we need to do things this way.

Glad you like it... I'm hoping to push out the next part later this week, and I've got a few more drafts queued up that "just" needs some proofreading. Working on getting it to the point where it can fully compile itself now, and hope to get there over the couple of months.

I've been reading this series with interest for years. Thank you for writing it.

Re: Kernel 101 – Let’s write a Kernel

#95
The first question is:

Why?

We already have a whole bunch of operating systems, many of them free.

One of the frequent problems with a lot of free/open source software folks is that they lack direction. This type of thing where we do stuff just to do stuff probably won't fly in one of the leading tech companies.

Why don't you figure out a real problem people have and look for ways to solve that, instead of just doing random "interesting" stuff that wastes people's valuable time?

Re: Kernel 101 – Let’s write a Kernel

#96
post #12

Earlier quoted context omitted.

Reminds me of the old "booter" games on the PC that used their own kernel instead of MS DOS [1] It would be fun to see how far one could go with modern hardware. Writing your own driver for a modern graphics card sounds absolutely terrifying (and fun). [1] http://en.wikipedia.org/wiki/PC_booter

This one was awesome: http://en.wikipedia.org/wiki/Buck_Rogers:_Planet_of_Zoom#Pla... CGA graphics(!), and pushed the monophonic speaker on a basic XT further than anything I'd seen at the time. Unplayable on "turbo" mode :-)

I have a version of that on cartridge for my TI-99/4A!

Re: Kernel 101 – Let’s write a Kernel

#97
post #87

Earlier quoted context omitted.

This makes me really sad. 32bit mode x86 assembly is such a mess compared to amd64 -- I guess it's a good excuse to work with qemu and arm, if nothing else ;-)

On the topic of ARM, does anybody know of a similar example like this for ARM? One that just shows you how to pass control to C and do some basic I/O?

Too late to edit my post, but I eventually found this: http://wiki.osdev.org/ARM_Integrator-CP_Bare_Bones. I haven't tried it out yet as I'm still getting the cross-compiler toolchain together (doesn't seem to be part of OpenSUSE 12, at least not an obvious part), and it's not as well explained, but still the best I've found.

Re: Kernel 101 – Let’s write a Kernel

#98

Looks great, will keep an eye on this! I also really enjoyed James Molloy's OS kernel development tutorial at http://www.jamesmolloy.co.uk/tutorial_html/ , which takes you from "Hello World" to some real toy OS kernel implementation.

It's worth pointing out there are a few bugs in James Molloy's tutorial [1], and some of the things he does in them aren't exactly best practices - for example, a few I remember are: - Disabling interrupts and paging (which also has the side effect of flushing the TLB) to copy memory around by physical address. This could be done without disabling them by mapping all of physical memory into virtual memory instead (po…

Oh, didn't know there was a follow-up to his original tutorial - I'll have a look at your resources when I get back from work!

Re: Kernel 101 – Let’s write a Kernel

#100
I have done the same, sort of, only eschewing BIOS for UEFI and thus getting straight to Long Mode :-).

It's pretty basic, currently just boots up and prints the memory map.

It's written in C++11 with the aim to be as clear as possible: https://github.com/thasenpusch/simplix Have a look :-).

Post reply on HN