OS dev easier than it's made out to be?
OS dev easier than it's made out to be?
So, I'm a C/asm newbie (I can program C, but not asm, I can understand C, kind of asm), and yet reading the sources of the various projects around here is very easy, and most of them make sense. It seems above the very core kernel, it's just lightweight C. Is this true, or does it get worse in most cases?
"Any bug is trivial once it is found." (Programmer's Proverb)
OS dev is no "black magic" or something. We don't use some arcane code constructs that nobody else uses.
The problems arise from the environments: You can't run your bootsector in a GUI debugger like you can with userspace apps. You have to look up details of CPU architecture in technical documents that make your bookshelf groan under their weight. If you don't take care, you get a hard reboot instead of a diagnostic error message. And you have to work long and hard before you reach a point where your project is actually functional - while your chances of ever creating something useful are slim.
I'd rather say that OS dev'ing is made almost too easy, because lots of young people are jumping at it without ever having created anything useful in user space...
OS dev is no "black magic" or something. We don't use some arcane code constructs that nobody else uses.
The problems arise from the environments: You can't run your bootsector in a GUI debugger like you can with userspace apps. You have to look up details of CPU architecture in technical documents that make your bookshelf groan under their weight. If you don't take care, you get a hard reboot instead of a diagnostic error message. And you have to work long and hard before you reach a point where your project is actually functional - while your chances of ever creating something useful are slim.
I'd rather say that OS dev'ing is made almost too easy, because lots of young people are jumping at it without ever having created anything useful in user space...
Every good solution is obvious once you've found it.
Well, of courseSolar wrote:"Any bug is trivial once it is found." (Programmer's Proverb)
OS dev is no "black magic" or something. We don't use some arcane code constructs that nobody else uses.
I generally find myself never using a gui debugger, most of the time. The functional/useful point is debtable - I, personally, feel home with "vi" and "gcc"Solar wrote: The problems arise from the environments: You can't run your bootsector in a GUI debugger like you can with userspace apps. You have to look up details of CPU architecture in technical documents that make your bookshelf groan under their weight. If you don't take care, you get a hard reboot instead of a diagnostic error message. And you have to work long and hard before you reach a point where your project is actually functional - while your chances of ever creating something useful are slim.
- but again, I guess that involves writing/porting a shell, getting ncurses+vi running, and cross-compiling gcc to run on your system.Still, the code I'm reading is better than the "100% inline assembly hooray!" i was expecting.
Re: OS dev easier than it's made out to be?
Hi,
For an example, it's possible to write a simple round robin scheduler for single CPU systems with (relatively) little work. A modern high performance prioritized scheduler with several scheduling policies, SMP support, optimizations for NUMA, hyper-threading and shared caches, accurate time accountancy, delayed FPU/MMX/SSE state saving and very low lock contention can take 50 times as long to write.
Of course there's an interface to the kernel that is usually designed to hide as much of the complexity as possible - so that (for e.g.) an application programmer can use simpler functions without knowing all the messy details.
Device drivers are a little different though, as they're usually much closer to the kernel core. Sometimes I think the device driver interface is the most revealing part of an OS, because it's a more difficult compromise between exposing kernel details and providing clean abstractions.
Cheers,
Brendan
For OS development, there's "easy" and there's "complex", with a large variety in-between.ehird wrote:So, I'm a C/asm newbie (I can program C, but not asm, I can understand C, kind of asm), and yet reading the sources of the various projects around here is very easy, and most of them make sense. It seems above the very core kernel, it's just lightweight C. Is this true, or does it get worse in most cases?
For an example, it's possible to write a simple round robin scheduler for single CPU systems with (relatively) little work. A modern high performance prioritized scheduler with several scheduling policies, SMP support, optimizations for NUMA, hyper-threading and shared caches, accurate time accountancy, delayed FPU/MMX/SSE state saving and very low lock contention can take 50 times as long to write.
Of course there's an interface to the kernel that is usually designed to hide as much of the complexity as possible - so that (for e.g.) an application programmer can use simpler functions without knowing all the messy details.
Device drivers are a little different though, as they're usually much closer to the kernel core. Sometimes I think the device driver interface is the most revealing part of an OS, because it's a more difficult compromise between exposing kernel details and providing clean abstractions.
Cheers,
Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
Such as placement new, stack switching and so forth? No, you don't get those problems, nor their solutions or methods of thought in other disciplines.Solar wrote:OS dev is no "black magic" or something. We don't use some arcane code constructs that nobody else uses.
I would say that OS dev is fairly easy if you design little and aim low. Pretty much the same as jumping 10cm / 1/3 ft would be. If you try to jump 3ft/1m you're going to have to try quite hard and expect to fail. If you try to jump 2m / 6ft, you're most likely going to fail.
Hacking a binary together that can load other binaries and jump to them is fairly easy. Making one that has proper interfaces you can call is less easy. Making one that is not trivial in more than one aspect (such as those that Brendan summed up for a scheduler above) is hard.
When you implement the really low-level abstraction layers, like ISRs and stack-switching, there can be some magic, but most people understand it after a time. Actual black art, obtained by selling one's soul to Asmodeus, is relatively rare except when you want the hardware to act contrary to its nature.