James Molloy's Known Bugs

[sortie]

Hey,

I took the liberty of writing a wiki article on James Molloy's Known Bugs (akin to Bran's Known Bugs). This just a first draft, but I think I covered the most pressing issues.

Like many others, I started out with the tutorial. I really appreciate its existence, but it is no secret that it is flawed. While I managed to avoid some the critical flaws (kernel stack forking!), many minor ones unfortunately made their way into my operating system. I've finally purged these flaws myself, but I continue to see newcomers follow the tutorial and even other regulars still have some of the problems. I hear James is working on a new tutorial, but since this one is already popular I found it fitting to make a list; I'm almost surprised that one didn't already exist. In many cases the fix is simply following Bare Bones instead and disregarding the tutorial's advise in favour of our wiki.

I haven't been closely through the article or spell-checked my draft yet, please feel free to contribute to the article. I recognize that some of my points are somewhat subjective, though it is things I would change had it been on wiki.osdev.org. The intention is that we can link newcomers to this article as an aid if they decide to follow the tutorial.

[Pancakes]

Awesome, I never knew it had those bugs in it. I never followed it but just reading your new page really enlightened me. I had forgot all about the heap needing to be aligned, duh!. I even remember having this problem a few years ago and forgot all about it. So a very good page even if you do not use the tutorial.

[Jezze]

Very good. Luckily I dont use hardly anything from that tutorial anymore but I remember some of the wtfs in there. There was one thing that caught my attention though? Is it possible to have interrupts disabled by the setting it in the idt entry? I read the article on idt but could not find any information on that. How is it done?

Nevermind, I found it. Good Ive learned something today.

[qw]

Nice job. I haven't followed the tutorial so I can't really tell, but it looks like quite a comprehensive list to me.

[Lionel]

Sorry to (very very early) necromance, but I think we should make this much more visible. I only found it by chance, but if so many people are following it then we need to inform them of the bugs.
For instance, in the tutorials section, directly under the link we can have a message with a link to this page.

Or, we could make a "James Molloy Tutorial" page with info and bugs about the tutorial, some general warnings, and of course the tutorial. There's also an experimental version of the tutorial which we could also link. ( I might work on this page in my userspace anyways...)

Does this sound like a good idea?

[sortie]

I added a link on the Tutorials place. Please let me know if you see any other places a link would be suitable. The article is rather new though I have been posting it a bunch here since then. We only need some awareness from the forum regulars so they know to post it when they see tell-tale signs someone followed it.

Necromancy? This topic isn't even 14 days old.

[Lionel]

I didn't say very very very early necromancy for nothing

[JamesM]

Hi,

Thanks for making this. It's good to know that someone at least has found and categorised all the bugs (although I notice noone mentioned the amazing arithmetic for page-aligning something in the heap: "x & 0xFFF" (!!!)).

I do not have time to update this or to work on the followup tutorials at all at the moment, and that is unlikely to change no matter how much I wish it might.

I have written a new version here: https://github.com/jmolloy/JMTK . I've described it as a "teaching kernel" more than a tutorial, and have attempted to document it in a similar way. It is less of a walkthrough than the previous version, and it is MUCH better written. The previous version was written in around 2007 when I was a second-year university student. Stuff like u32int instead of uint32_t was inherited from the coding style at the company I was on a placement with.

The teaching kernel is structured differently to a tutorial. Instead of "chapters" in a linear progression, it is a directed graph with each arc adding functionality. One can choose one's own route to the functionality you want, skipping the stuff you find useless.

If someone wants to fork this kernel and complete it, or advertise it as-is, I'm perfectly happy. I won't have time to complete it. I'm particularly pleased with the general "plug-n-play" design for adding functionality, the kernel heap and the paging code.

The design stems from the requirement of being able to effectively maintain a project that exists in multiple states simultaneously - different subsets of the code are used for each chapter and an update to one file must find its way into all chapters that use that file. So this works, I designed it to be purely additive. Successive chapters could ONLY add files. They couldn't modify or remove previously existing files. This means there are no diffs between chapters and partitioning it up is easy. This made it quite an attractive design in the end.

Anyway, I hope someone finds a use for it. I think there is a place in the world for an introductory kernel that is larger in scope than the wiki barebones and bridges the gap between theory and practical that my original kernel tutorial tried to do.

By the way, I totally disagree with the requirement in the barebones of a cross compiler. With good use of -nostdlibinc you can get access to the compiler headers (stdint.h and friends) without the OS headers. Also not requiring a cross compiler makes the thing infinitely more accessible. I'd appreciate if people could stop spouting "you need a crosscompiler" without really really good reason (and I now work as a compiler engineer so they really need to be good reasons )

EDIT: Oh, the really cool thing about this is that it can also run as a Linux hosted process! which means you can debug your heap code or threading code with GDB on a hosted box. And it has a bunch of regression tests both for hosted mode and for baremetal mode (which are run using qemu).

Cheers,

James

[Brynet-Inc]

Welcome back!

By the way, I totally disagree with the requirement in the barebones of a cross compiler. With good use of -nostdlibinc you can get access to the compiler headers (stdint.h and friends) without the OS headers. Also not requiring a cross compiler makes the thing infinitely more accessible. I'd appreciate if people could stop spouting "you need a crosscompiler" without really really good reason (and I now work as a compiler engineer so they really need to be good reasons )

Then you know that compiler distributions often contain vendor patches that change default behaviour. Recommending a cross-compiler has always been about creating a reproducible build environment using the vanilla upstream sources. Nobody is claiming that you can't use your host compiler, only that it will almost certainly not be the same one I'm using.