OSDev.org

Edit: In light of convincing argumentation by Gravaera, most parts of the tutorial have been removed.

Hi.

I started a new series of OSDEV tutorials mostly to have something to fill my blawg with...
http://www.thomasloven.com/P7/OSDEV-tutorials/

Please, let me know what you think.

Hello,

I also wanted to write a tutorial series, but for me designing my uber-cool OS is a bigger aim.

Anyway, I browsed through parts of the tutorial. I may have missed something. I never say I read all of it, and my browsing is equal to skimming. But I think my observation was good enough to pass comments on your tutorial.

You seem to have the wrong idea's about tutorials. Tutorials aren't meant to provide code by which the reader can copy-paste to make a OS. You seem to provide good code, without any good explanation. Your explanation tells us what the code does. Rather, you should say what the code does, how it does, why it does, how the architecture works.

For example, you never explain why a PMM is needed, what Paging is, how it works. Moreover, you should use more links. For example, explain paging and give links to http://wiki.osdev.org/Paging , http://wiki.osdev.org/PAE , etc , etc.

Other than that, also try to write more simpler code in blocks, i.e. first write some parts, then explanation and so on and so forth.

Regards,
Shikhin

Good going

Shikhin wrote: You seem to have the wrong idea's about tutorials. Tutorials aren't meant to provide code by which the reader can copy-paste to make a OS. You seem to provide good code, without any good explanation. Your explanation tells us what the code does. Rather, you should say what the code does, how it does, why it does, how the architecture works.

Thanks for the input.
I guess I am spoonfeeding too much and teaching too little. I just rewrote the bootstrapping tutorial to explain a bit more - personally I like it much better now anyway.
Also, having a screen printing tutorial is a bit pointless if I assume my readers have both read bkerndev and JamesMs tutorials, so that one will probably go soon.

I do not agree on your thoughts on linking, though. Too many links can easily become distracting and confusing. Still, I'll try to point towards more information when possible.

Best regards
/ Thomas

The series is terrible. You don't know C anymore than an average highschool student does, you make all sorts of mistakes and yet you wish to write an operating system tutorial, so as to teach people how to suck at this. I'm sorry for being rude but someone had to tell you. Come back when you are ready. Until then, check your own page for prerequisites and follow the instructions therein.

P.S.: I took a few minutes out of my precious time and posted comments on every one of your tutorials, pointing out many problems (that list is not by any means exhaustive, fyi).

Actually the biggest problem out there today with the information available to new developers is exactly this: sources of information that are meant for a very specific platform, which do not show proper abstraction technique, professing themselves to be generic kernel theory. This pretty much confuses everything, and due to the lack of abstraction and proper component isolation it makes it very hard for newcomers to separate things that should be separate concepts, and they end up confusing many things with each other and generally making a mess.

I'm sure some saint is going to come and try to defend the OP and generally imply repeatedly that I'm a jerk, so I'll give concrete examples of why this series a bad thing: From this page alone: http://www.thomasloven.com/P12/OSDEV-tu ... strapping/

The very first section, "linker script" makes a grievous error: You start off by saying, "The first thing we need is a linker script". Bam. 1. The linker script is very specific to GNU LD, and its format and everything is specific to GNU LD. Yet the way you word that paragraph implies to a newbie that "A linker script" is something which is written exactly the way you gave it in the article, and it is a "required item" that makes up a kernel. Whereas if you're not using the GNU toolchain, the idea of a linker script is probably entirely unnecessary, since not all linkers use linker scripts. Statically stating a sequence of steps, and not clarifying, justifying or disambiguating any of it.

Then in that same paragraph, you go ahead and state something very architecture specific. You say,

"We want our kernel compiled to run at somewhere above 0xC0000000."

There are many new developers who think that x86-32 is irrelevant and are moving directly into x86-64. You make no mention of the fact that this kernel location is done because x86-32 has a 32-bit virtual address space, and so you're bascially trying to gauge how much space would be adequate for userspace and how much would be sufficient for the kernel. You also give another static idea: that the kernel must have the address space split done as 3-GB-userspace-1-GB-kernelspace. NT does a 2GB-2GB split, and there are kernels which do not map the entire kernel into each process, and give the kernel its own address space. The OS/X kernel on x86-64 does this IIRC. Again, giving random steps, no explanation, no proper abstract theory, no justification of your statements. So imagine an excited newcomer goes and reads your "tutorials" and tries to do an x86-64 "barebones" or whatever he calls it, and then he moves on with a 3GB userspace for x86-64.

When GRUB loads the kernel, however paging will not be enabled, so it could only be loaded there if our system had three gigabytes of physical memory, which we can't always assume. Luckily, we can get GRUB to load the kernel to 0x100000, but make the kernel run as if it was at 0xC0100000 using a simple linker trick.

And here's a technical fallacy: GrUB cannot make your kernel run as if it were at any address. You have now made the newcomer associate functionality that GrUB does not have with GrUB, thereby blurring the lines of separation between distinct entities with distinct responsibilities. GrUB is told where to load the kernel in physical memory; you must make sure that the entry point for the kernel is also a physical address. These are your responsibilities. GrUB does not care about how your kernel is linked virtually.

Also, you cannot not make the kernel run as if it was loaded at 0xC0100000 until you enable paging; paging is the mechanism used to achieve that effect. Before that you should have the kernel linked physically, then you enable paging and do a "JMP imm32" instruction to load EIP with a virtual address after you've enabled paging and mapped the kernel to the higher half; before that it should be executing in pure physical mode. The alternatives are to (1) use the "GDT trick", or (2) enable paging as soon as the kernel enters scope. But you don't make the kernel run "as if it was at 0xC0100000 using a linker script trick". First of all, the linker script has no effect on the address translation logic within the CPU which is what you use to actually perform the tricks necessary to keep the kernel executing when paging is still off.

All of this is just in the first paragraph, and along with it, in the simple skim I did, I saw other things, both major and minor, subtle and obvious, all of which work together to produce the combined effect of creating yet another highly misguided newcomer who then proceeds to compile the code in your "tutorial", see that it's not working the way he understood it, and then come and make a completely confused post.

I recommend you review the tutorial series and polish it up before releasing it again By all means feel free to write new articles, and try to give out information, but please don't release possibly damaging information

EDIT:

I just went and looked at the table of contents again, and the next chapter is titled: "Screen printing". Please correctly rename it "Manipulating a VGA compatible card in alphanumeric mode". The VGA standard's alphanumeric mode is by no means a generic way of "printing to the screen", and outside the VGA standard there are actually very few modern video cards which, if not for support of the VGA standard, would support an alphanumeric mode of operation. The correct way to go about that chapter of the series is to state very clearly the following:

1. IBM-PC compatibles come with a "VGA function" as the PC manuals call it. This is a specified component of a PC compatible and can be assumed to be there. Since it is required on all PC-compatibles, modern PC-compatibles which have more powerful graphics card emulate the VGA function by having the card emulate a "VGA mode" which complies with the PC VGA standard.

2. That the article series is fixed to the x86-32/PC platform, so it assumes the use of a PC chipset for testing.

3. Since the tutorial kernel is written specifically for x86-32/IBM-PC, you can assume the presence of a card with a usable VGA mode.

4. Now you can go on to explaining how the VGA compatible card operates within alphanumeric mode.

But don't go about confusing things by making it seem like "in order to print to the screen, you must write characters to 0xB8000". This is again a case of unjustified absolute statements being presented to a newcomer, who then forms some set of flawed assumptions and goes about writing code based on it.

EDIT:

As a final note, don't feel shot down or anything: the majority of other "tutorial" series out there right now are just as bad or worse. This wasn't an attempt to bash you or anything: you probably didn't see those flaws yourself...which is why you should probably review and polish the series, then republish it. In reading Love4Boobies' comments on the site, it seems he was more interested in the correctness of your C coding, which is to me rather insignificant in comparison to the REAL monsters lurking in those pages: the set of both subtle and damaging flaws which come together to form the basis of terrible misconceptions in newcomers. He was more interested in the coding style, and I was more worried about the effect of the inaccuracy of the information presented and the implication it would have as a larger work after being read in its entirety.

--All the best
gravaera

Yes, I mosty pointed out some problems with his C and assembly code, but as you'll notice, I did mention some of the problems you're talking about like being tied to a specific architecture and a specific toolchain:

Perhaps it would be a good idea to specify that this tutorial series covers x86(-64?) only

First of all, you should specify that you're using GNU Make, as these makefiles are not POSIX-compliant.

However, I didn't spend more than a few minutes looking over the series, as can be seen by the comment timestamps However, you made the most important point IMO: these tutorials describe what his code does rather than why it's doing it. Unfortunately, that seems to be the case with almost all tutorials I've come across so I took that for granted.

Love4Boobies wrote:...
You don't know C anymore than an average highschool student does,...

I thought what mattered was that I know a bit more about operating systems than the average highschool student. I think, by the way, that I would have loved to go to your highschool...
Anyway, you both make really good points. I never thought that it could hurt anyone to post this, but of course you are right.

I appreciate criticism, and especially constructive such - like your comments on the blog, Love4Boobies. Makes me motivated to write more. While I disagree with some of your points, I'll take them into consideration, and will probably return with new posts someday - hopefully of much higher quality. Until then, everything but the cross compiler chapter has been removed.

If noone has anything else to add, I would like this topic locked.

Best regards
/ Thomas

Edit: By the way, both of your lines of argumentation suggest that it was unclear that the tutorials were supposed to be read in some kind of order. Was this the case? If so; any ideas on how I can make that clearer? An index at the beginning of every post, perhaps?