3 ms·
True that it's invisible to end-users, but it's still a pain in the ass to people writing OSes. Lowering the barrier to entry even a little bit will be apprecia
by kibwen 3y ago
True that it's invisible to end-users, but it's still a pain in the ass to people writing OSes. Lowering the barrier to entry even a little bit will be appreciated by hobbyists.
- t0b1 3y agoHow so? The bootloader already runs in long mode with UEFI and it also takes care of bringing up other cores so this is not really a problem in my experience.
- JoshTriplett 3y agoLinux still needs to use a Startup IPI to bring up other CPUs, which starts them running in 16-bit mode at an address under 1MB. Having a fully 64-bit way to bring up other CPUs would simplify that.
- monocasa 3y agoUEFI doesn't really take care of bringing up the other cores. There's a way to get access to them, but you have to give them back to UEFI before exiting boot services, so that doesn't really help your kernel. You still need to do the SIPI into x86-16 code to really take control of the AP cores. Even the new way (that isn't actually implemented AFAIK) just SIPIs into long mode code, it doesn't use the UEFI multicore stuff.
- DSMan195276 3y agoFrom a hobbies point of view I'd actually argue the opposite. The nice thing about the old stuff (Ex. the 8259 PIC support they're removing here) is that it's much simpler to get going. They have very large limitations, but those don't matter when just starting, and they serve as a good stepping stone and learning opportunity before eventually moving on to the modern and more complicated stuff. Additionally if you're using a bootloader then the bulk of this is already solved for you anyway.
- rbanffy 3y agoThe modern stuff is only more complicated because it had to be built around and on top of dozens of dead civilisations under it.
- hulitu 3y agoThis is the simplistic explanation. I think that besides that, some people are paid for complexity. That would justify the evolution of SW in the last 10 years.