The Place to Start for Operating System Developers
https://f.osdev.org/
Code: Select all
out 0x3D4, 14Not just that. The linker script (first one) is wrong, struct gdt is wrong, and that is just what immediately draws attention. Overall, the little book seems to be written by people who have done little to no testing of their code snippets.Combuster wrote:Look, it doesn't assemble!
Posting a beginners guide that contains errors that are hard for beginners to identify and debug does more harm than good.willedwards wrote:I posted this thinking it a good, useful resource for everyone especially beginners.
Could you please define what a genuine fault is so that I don't bother you with my immaturity anymore?willedwards wrote:Anyone who has found a genuine fault with the guide can submit issues or, better yet, pull-request corrections at https://github.com/littleosbook/littleosbook
Which is a good thing. But irrelevant to the guide in question because the code excerpts in the two locations don't match.willedwards wrote:The source-code for the actual OS is available online https://github.com/helino/aenix and it does - obviously - build ok.
There are definitely other mistakes in the book! I have created an issue for adding information about using a cross-compiler: https://github.com/littleosbook/littleosbook/issues/12. Just a question though, since the OS created in the guide is for x86, and the user is most likely using an x86-64 CPU, isn't passing -m32 to gcc enough (as well as other flags to not use standard headers, libc etc)?Octocontrabass wrote:The tutorial says nothing about a cross-compiler. You need a cross-compiler for OS development.
I haven't read through all of it, but I wouldn't be surprised if there are other mistakes.
An issue has been filed, see https://github.com/littleosbook/littleosbook/issues/10Icee wrote:Not just that. The linker script (first one) is wrong,Combuster wrote:Look, it doesn't assemble!
Issue filed: https://github.com/littleosbook/littleosbook/issues/13Icee wrote:struct gdt is wrong
Hmm, yes, we should definetely try add tests for the snippets in the book to avoid (embarassing) issues like these. Filed an issue for this as well:Icee wrote:and that is just what immediately draws attention. Overall, the little book seems to be written by people who have done little to no testing of their code snippets.
Filed https://github.com/littleosbook/littleosbook/issues/15. Thanks for all the feedback, much appreciated!Icee wrote:UPD: oh, the IDT loading code is wrong, too.
Agree, but thanks to feedback from everyone in here (as well as from reddit and github), this can hopefully become a correct beginner friendly guide. The other alternative would of course have been to not publish this at all, hopefully people can get some value out of it (even in its current state).Icee wrote:Posting a beginners guide that contains errors that are hard for beginners to identify and debug does more harm than good.willedwards wrote:I posted this thinking it a good, useful resource for everyone especially beginners.
I don't think your replies are immature, again, the feedback is much appreciated! Feel free to post any errors in this thread, or open an issue on github.Icee wrote:Could you please define what a genuine fault is so that I don't bother you with my immaturity anymore?willedwards wrote:Anyone who has found a genuine fault with the guide can submit issues or, better yet, pull-request corrections at https://github.com/littleosbook/littleosbook
Agreed, this needs to be fixed.Icee wrote:Which is a good thing. But irrelevant to the guide in question because the code excerpts in the two locations don't match.willedwards wrote:The source-code for the actual OS is available online https://github.com/helino/aenix and it does - obviously - build ok.
That depends on what is considered a critical fault. It starts with "ubuntu" while basically it requires a specifically 64-bit linux (i.e. 32-bit ubuntu would break as well). It also seems to suggest flat binaries for applications and relies on undefined behaviour to start them where they are supposed to be started. If you add to that the syntax errors present in the document, it quickly comes to the point of another schoolkid having done something and next thing we know is that we have to support yet another broken tutorial and likely remind them of the "Is there a tutorial on" beginner mistake.I'm a bit taken aback by how quick people are to dismiss it and think they've found some critical fault. I didn't post this so the immature could feel superior!
No, it's not enough. The root issue is that the gcc that comes with your Linux is a compiler for Linux, and your OS is not Linux. It's that simple. Any issues that arise and you have to work around comes from this fact. You're lying to the compiler, rather than working with it.helino wrote:There are definitely other mistakes in the book! I have created an issue for adding information about using a cross-compiler: https://github.com/littleosbook/littleosbook/issues/12. Just a question though, since the OS created in the guide is for x86, and the user is most likely using an x86-64 CPU, isn't passing -m32 to gcc enough (as well as other flags to not use standard headers, libc etc)?
Code: Select all
-m32 -nostdlib -nostdinc -fno-builtin -fno-stack-protector -nostartfile -nodefaultlibsMany distro's these days have patched GCCs - you'll already see that happen with the necessity of -fno-stack-protector which isn't needed on a vanilla gcc for linux, nor the cross-compiler. As far as the documentation goes, the ubuntu compiler also hard-depends on a patched version of glibc and will potentially break again the moment you start adding libc-named functions. You would also need to forcibly disable PIC to support the default hardened compiler settings on some non-ubuntu linuxes.helino wrote:There are definitely other mistakes in the book! I have created an issue for adding information about using a cross-compiler: https://github.com/littleosbook/littleosbook/issues/12. Just a question though, since the OS created in the guide is for x86, and the user is most likely using an x86-64 CPU, isn't passing -m32 to gcc enough (as well as other flags to not use standard headers, libc etc)?
In fact, there actually is no such thing as a proper way to write an OS.sortie wrote:Teach them how a proper OS would do it.
Don't fall victim to that kind of thinking. When implementating operating systems features, you often have the option between doing it well or doing it in a hacky way. I'm not talking perfection, but simple, good correctness. I've seen a lot of systems take the quick and dirty route, and they've paid for it later on. Instead of implementing a qsort that uses insertion sort and does lots of memory allocations that fail, you should do a proper O(n log n) implementation. It doesn't need to be fast, but it's decent and correct. Stuff like not using a cross-compiler and other dirty hacks done early on just gets some pleasure now in exchange for trouble later. I've spent a lot of time rewriting and making my OS better, when I should just have done things properly early on. If you can see issues with your implementation and can imagine a considerably better implementation, implement that instead.Chandra wrote:In fact, there actually is no such thing as a proper way to write an OS.sortie wrote:Teach them how a proper OS would do it.