Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Kernel 101 – Let’s write a Kernel

arjunsreedharan.org

Post reply on HN
Print view View original

41–50 of 104 posts

Re: Kernel 101 – Let’s write a Kernel

#41

Post by breadbox »

aaren wrote: post #24

Can anyone give me an idea how much different this would be for 64bit? Do I just change the nasm directive to `bits 64`?

... and the gcc flag would need to be -m64. But I don't think it's this easy. If grub is in 32-bit mode when it hands you control, I would think you would need to switch to Long Mode before you could execute 64-bit code. So your entry point would still have to be a 32-bit program, which would set up everything necessary for Long Mode, make the switch, and then load and execute the 64-bit part of your program.

Re: Kernel 101 – Let’s write a Kernel

#42

Post by akiselev »

aaren wrote: post #24

Can anyone give me an idea how much different this would be for 64bit? Do I just change the nasm directive to `bits 64`?

According to [1] in the section on initializing from reset, Intel CPUs boot to one of three modes:

* Read mode has 1MB of memory and is 16 bit.

* Flat protected mode which is 32 bit and takes interrupts

* Segmented Protected mode which is 64 bit (w/ 32 bit emulation) and is used by operating systems to protect memory

In this tutorial, your boot mode depends on what GRUB boots you in.

[1] http://www.intel.com/content/dam/www/public/us/en/documents/...

Re: Kernel 101 – Let’s write a Kernel

#43

Post by Dewie »

bebop wrote: post #31
mbillie1 wrote: post #21

Earlier quoted context omitted.

I've found myself spending a lot more time here as well. Was there any code/policy change with the HN site? Or is this new moderators jumping in and helping out a lot? Either way, I agree that it is excellent.

About a week or two ago pg added moderation. I cannot find the thread right now, but basically comments are not published until someone with high enough karma (I think 1000 points) approves the comment.

I saw that thread, but I didn't think it was being enforced. I haven't experienced any difference these last weeks.

Re: Kernel 101 – Let’s write a Kernel

#44

Post by akiselev »

TehCorwiz wrote: post #8
kyberias wrote: post #5

I'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…

http://en.wikipedia.org/wiki/Microkernel

This isn't even a microkernel. This would at best be an example of firmware on an Intel/AMD x86/x64 booted from Grub that prints to the console.

This code, however, doesn't do a single thing that other software expect even a microkernel to do (provide for basic scheduling, memory management if an MMU is available [which it is in this case], and IPC/FS).

Re: Kernel 101 – Let’s write a Kernel

#45

Post by dragonwriter »

slashdotaccount wrote: post #11
kyberias wrote: post #5

I'm not exactly Linus Torvalds but I'm pretty sure a program that prints one line of text is not "a kernel". :)

If someone here has gone to college, then they'll know what 101 means - course numbering.

> If someone here has gone to college, then they'll know what 101 means - course numbering.

At most colleges whose course numbering system I've seen, the kind of introductory course that the idiom "101" refers to would actually be "1"; at many of them, "101" would be an upper division class. Its an idiom that may have connected to some colleges' numbering system at some time, but it mostly exists independently now, and actually going to college doesn't actually make its intended meaning any more obvious.

Re: Kernel 101 – Let’s write a Kernel

#46

Post by nwg »

aortega wrote: post #30
nwg wrote: post #28

Earlier quoted context omitted.

So if you write core software for an architecture without privsep you must not call it a kernel?

I'm not talking about privsep, just different modules. I gonna answer you with another question: Did MS-DOS had a kernel?

Yes. We all lose here today.

Re: Kernel 101 – Let’s write a Kernel

#47

Post by steveklabnik »

akiselev wrote: post #44
TehCorwiz wrote: post #8

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…

http://en.wikipedia.org/wiki/Microkernel This isn't even a microkernel. This would at best be an example of firmware on an Intel/AMD x86/x64 booted from Grub that prints to the console. This code, however, doesn't do a single thing that other software expect even a microkernel to do (provide for basic scheduling, memory management if an MMU is available [which it is in this case], and IPC/FS).

http://en.wikipedia.org/wiki/Exokernel <- if you're playing the 'how big is a kernel' game.

Re: Kernel 101 – Let’s write a Kernel

#48

Post by steveklabnik »

bebop wrote: post #31
mbillie1 wrote: post #21

Earlier quoted context omitted.

I've found myself spending a lot more time here as well. Was there any code/policy change with the HN site? Or is this new moderators jumping in and helping out a lot? Either way, I agree that it is excellent.

About a week or two ago pg added moderation. I cannot find the thread right now, but basically comments are not published until someone with high enough karma (I think 1000 points) approves the comment.

That's only for threads where it's been turned on.

Re: Kernel 101 – Let’s write a Kernel

#49

Post by aortega »

nwg wrote: post #46
aortega wrote: post #30

Earlier quoted context omitted.

I'm not talking about privsep, just different modules. I gonna answer you with another question: Did MS-DOS had a kernel?

Yes. We all lose here today.

It depends. Being downvoted by people that believes a memcpy() is a kernel, is victory.

Re: Kernel 101 – Let’s write a Kernel

#50

Post by akiselev »

steveklabnik wrote: post #47
akiselev wrote: post #44

Earlier quoted context omitted.

http://en.wikipedia.org/wiki/Microkernel This isn't even a microkernel. This would at best be an example of firmware on an Intel/AMD x86/x64 booted from Grub that prints to the console. This code, however, doesn't do a single thing that other software expect even a microkernel to do (provide for basic scheduling, memory management if an MMU is available [which it is in this case], and IPC/FS).

http://en.wikipedia.org/wiki/Exokernel <- if you're playing the 'how big is a kernel' game.

Awesome link, thanks!

The key part of any kernel can be expressed from this Exokernel definition:

   Exokernels are tiny, since functionality is limited to ensuring protection and multiplexing of resources, which are vastly simpler than conventional microkernels' implementation of message passing and monolithic kernels' implementation of abstractions.
They have to, in some way shape or form, deal with conflicting requests for resources from their client applications (whether or not you have a concept of privileged or protected execution like on basic microcontrollers). I'd be curious to see how exokernels manage time unless each application implements its own scheduler and gives up control of execution.
Post reply on HN