nullplan wrote:
We used to have to write arcane incantations in assembler to load our kernels, now we can write our bootloaders in C and aren't restricted to half a kilobyte. So that's a big plus.
I see it the other way around. we used to have a clean and easy to use interface to load our kernel, and half a kilobyte of code was enough to do that. Now we have to deal with extremely overcomplicated, badly designed, non-universal, non-portable stuff hidden behind bloated SDKs, and not even 64k is enough to load our kernel! See
Linus wrote:
EFI is this other Intel brain-damage (the first one being ACPI).
...
For example, instead of ACPI, we could just have had standardized hardware
(and a few tables to define things like numbers of CPU's etc). It would
have been simpler for everybody. But no, people seem to think that it's
somehow "better" to have wild and crazy hardware, and then have a really
complicated way of describing it - and driving it - dynamically.
So EFI has this cool shell, a loadable driver framework, and other nice
features. Where "nice" obviously means "much more complex than the simple
things they designed in the late seventies back when people were stupid
and just wanted things to work".
I share his opinion on this. 99.9999% of the time nobody cares nor wants a boot shell nor loadable driver support at boot time, makes just no sense. For things that you do need a configurable environment, like editing the kernel command line and specifying modules, well, they are already implemented in GRUB (on IA-64 too) and in other boot loaders, so having all of this in a firmware is completely unnecessary and just resource-wasting redundancy. By the time TianoCore shows up its logo, I can already boot my OS entirely with BIOS. Is this really "progress"?
nullplan wrote:
Problem is that there's lots and lots of outdated information flying around out there, and people interested in the topic are more likely to find the old information than the current stuff.
That's true.
nullplan wrote:
After loading the kernel, OS work has always been difficult. It is programming without a net (or, as one of our vendors put it, open heart surgery); if you have a bug in your interrupt handling, there is very little that might help you find it.
Wrong. Learn how to use your tools. Read
Kernel Debugging on the wiki. I've just realized how much VirtualBox debugger has evolved since the last time I've used it. In functionality it is now in par with bochs, and far better than GDB (you can list page translation walks for example, or dump PIC registers, etc. something unimaginable in GDB).
nullplan wrote:
Which is why I personally like to keep things as simple as possible, because then there is little that can go wrong.
On that I couldn't agree more
nullplan wrote:
I personally believe interest in OS development is waning because interest in the PC is waning. Give it time. Once the new computing world order has been established and we all know what kind of platform we are working on the next few decades, interest might be sparked again. Meanwhile, I will polish my interrupt handling code. And when all the world has moved on to ARM, I will buy a PowerPC development kit, just to show them.
Haha, good plan!
Cheers,
bzt