|
This Wiki will ''not'' be expanded into a beginner's handbook, because that is not its purpose. It is for answering the ''advanced'' questions that arise when people feel they're ready for the plunge into kernel space programming.
=== A Hard Truth ===
'''''No one who isn't already a seasoned developer with years of experience in several languages and environments should even be considering OS Dev yet. A decade of programming, including a few years of low-level coding in assembly language and/or a systems language such as C, is pretty much the minimum necessary to even understand the topic well enough to work in it.'''''
What's more, this is growing ever more true by the year, as the number of different 'standards', computer and mobile device models, peripherals, and design concepts continues to expand.
It was one thing for someone like Dennis Ritchie, Richard Greenblatt, Gary Kildall, or Steve Wozniak to write a simple OS for hardware which was relatively straight-forward in comparison to current machines, which they already knew intimately, and which had no standards specifications to adhere to or existing cruft to maintain backwards compatibility with. This is no longer true on current-generation stock hardware. Furthermore, each of them was already a seasoned engineer who had already done years of systems programming. Even then, they only provided the foundations for the systems; the bulk of the work was done by small armies of subordinate developers after the nucleus of the system--the kernel, in modern jargon--was in place.
There are exceptions to this rule, but not many; don't expect yourself to be that one in a thousand. If you think you are, read up on the [https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect Dunning-Kruger Effect] and consider the matter again.
Oh, and for the record, Linus Torvalds wasn't quite one of them--he was a graduate student when he wrote the Linux kernel and had been coding in C for years. While he was well short of that ten year mark, as a grad student who had turned his hobby into his master's thesis, he had more time on his hands to work on the project than most people would. In any case, the 'Linux 0.0.1' release he famously posted to USENET in 1991 was little more than a round-robin scheduler, nowhere close to a full system. Getting to that point took him a year. Get the picture?
While it is true that most of the contributors to this wiki started much sooner, for most of us, that was a mistake born out of a lack of experience. Most of the pioneers of this group had no idea of the sheer scale and complexity of even a small OS project, no inkling of what they were getting themselves into. This was a difficult pill to swallow, especially back '''before''' resources like this Wiki were widely available. We cannot force you to learn from our mistakes, but at least we can pass on this warning.
Now, you shouldn't get ''too'' discouraged by this; the point is not that you can't do this, but that--if you are like most of us were when we started out--you probably can't do it ''yet''. Patience can be a virtue when starting out on a project this large.
=== Is there a tutorial on...? ===
=== Booting Problems ===
Especially in early stages and with a self-built bootloader, the reason for booting problems is frequently that too few sectors are fetched from disk. Either adjust the amount of sectors you fetch from disk, or have the boot loader/second stage loader parse the file system.
<!-- TODO: Hmm, this doesn't seem appropriate for this particular tutorial and is somewhat outdated as we always recommend using a cross-compiler. I'll just comment this out for now. --~~~~
=== Strings ===
When your Kernel is written in C, gcc puts strings and constants in a special section called ''read-only data''. This section needs to be explicitly added in your linker script, otherwise it can cause all sorts of weird problems (unable to print text to the screen, kernel suddenly becoming 1MB larger, GRUB giving a loading error saying ''kernel too large'', etc). The section is called ''.rodata'' in [[ELF]] and ''.rdata'' in COFF/PE (the output format for MinGW/Cygwin). Building a [[GCC Cross-Compiler]] will help you to safely assume ''.rodata'' everywhere.
You could also tweak your linker script to include ''either'' section:
<syntaxhighlight lang="c">
// ...
.text 0x100000 {
*(.text)
*(.rodata*) /* <---- ELF Cross Compiler or ELF *NIX (eg. Linux) */
*(.rdata*) /* <---- COFF/PE MinGW or Cygwin on Windows */
}
// ...
</syntaxhighlight>
-->
== Troubleshooting / Asking for Help ==
Before asking for help on the forums or IRC, you should be taking all the possible steps to diagnose the nature of the problem yourself. In the case of problems like triple faults or "random" exceptions, it's a common mistake to make assumptions about the cause of a problem. Make use of a debugger or print statements to locate the exact point when an exception occurs. Using and emulator and a debugger (such as GDB and Bochs/QEMU) will help you to locate problems which are difficult to trace. If you provide some theory about the problem and actions you have already taken to solve it, people will be able to help you much easier (even if your theory is not correct, it at least gives people an idea of your views on the problem and the strategies you might have already tried, as well as what you might have missed).
| 