3 ms·

It's even easier to produce a hobby OS targeting UEFI these days; less direct ASM required (maybe not any?), and the firmware can provide lots of things for you

It's even easier to produce a hobby OS targeting UEFI these days; less direct ASM required (maybe not any?), and the firmware can provide lots of things for you, assuming you're willing to stay in boot services mode. Browsing https://uefi.org/specs/UEFI/2.10/index.html https://uefi.org/specs/UEFI/2.10/index.html, I see console text mode, loadable modules, compression, networking... the list goes on.

toast0 2y ago
Yeah, but most of those cool things go away when you leave boot services mode, and I think boot services also limits you to single core? My hobby OS doesn't have that much assembly. My one asm file [1] is 888 lines, but there's a lot of lazy repetion for my interrupt and error handlers, so I can get the interrupt/error number as a parameter in the C function. If I was lazier and had interrupts go directly to c functions, there wouldn't be that much left in assembly: setting up the stack and stuff for C which isn't that much code, really, task switching bits that were too weird to write in C, stack setup for new threads, trampolines for starting the non-boot processors. There's some inline assembly in the kernel too, but I don't think you'd be able to get rid of that. [1] https://github.com/russor/crazierl/blob/main/kernel_src/start.s https://github.com/russor/crazierl/blob/main/kernel_src/star...
- dwattttt 2y ago
  I don't think there's any particular reason for you to jump out of boot services mode if you're just having fun. Runtime mode means the firmware gives up control of devices etc, because you're meant to take over them. As far as the rest of the cores go, I don't think UEFI has much to say about them; you're expected to start them yourself once you've switched to runtime mode, so I expect that means they're just hanging out before then, e.g. during boot services time... you could just start them then.

toast0 2y ago

Yeah, but most of those cool things go away when you leave boot services mode, and I think boot services also limits you to single core? My hobby OS doesn't have that much assembly. My one asm file [1] is 888 lines, but there's a lot of lazy repetion for my interrupt and error handlers, so I can get the interrupt/error number as a parameter in the C function. If I was lazier and had interrupts go directly to c functions, there wouldn't be that much left in assembly: setting up the stack and stuff for C which isn't that much code, really, task switching bits that were too weird to write in C, stack setup for new threads, trampolines for starting the non-boot processors. There's some inline assembly in the kernel too, but I don't think you'd be able to get rid of that. [1] https://github.com/russor/crazierl/blob/main/kernel_src/start.s https://github.com/russor/crazierl/blob/main/kernel_src/star...

dwattttt 2y ago
I don't think there's any particular reason for you to jump out of boot services mode if you're just having fun. Runtime mode means the firmware gives up control of devices etc, because you're meant to take over them. As far as the rest of the cores go, I don't think UEFI has much to say about them; you're expected to start them yourself once you've switched to runtime mode, so I expect that means they're just hanging out before then, e.g. during boot services time... you could just start them then.