LWN: Comments on "Using Python to investigate EFI and ACPI"

Using Python to investigate EFI and ACPI

voltagex — Thu, 17 Sep 2015 03:14:46 +0000

How difficult would it be to turn BITS into a bootloader? e.g. Python hits a web service, retreives a kernel image and boots it. I can think of various cool uses for this - watch out iPXE!

Using Python to investigate EFI and ACPI

job — Fri, 04 Sep 2015 17:57:56 +0000

> If the BIOS did not know about the hardware, the system couldn't talk to it.

That's a little strange statement. A lot of hardware was accessed directly at the time, and it didn't matter if BIOS knew about it. The rest were mostly ROM.

Using Python to investigate EFI and ACPI

josh — Fri, 04 Sep 2015 14:21:52 +0000

Unfortunately no; LinuxCon and Plumbers don't currently record their sessions.

There aren't many basic questions about EFI and ACPI. :) And I really don't mind answering basic questions. But if you don't want to post them here, feel free to ask via private email.

Using Python to investigate EFI and ACPI

rbrito — Fri, 04 Sep 2015 12:57:11 +0000

Were the presentations recorded?

I'd love to see this after having seen your PyCon video, Josh. I also have some questions, but they are so basic that I would be embarrassed to list them publicly. :)

Thanks. :)

Using Python to investigate EFI and ACPI

josh — Thu, 03 Sep 2015 20:48:18 +0000

True; I was trying not to nitpick that. :)

COM1 is what it happened to be called on this version of the qemu firmware; in past versions I've seen it called UAR1 (for a UART). The PNP ID or magic number in the _HID is what says "I'm a plug-and-play serial port".

Using Python to investigate EFI and ACPI

pbonzini — Thu, 03 Sep 2015 20:41:16 +0000

Great summary indeed! Just one nit: COM1 is not the magic name that the OS looks for. Instead, COM1 has a "_HID" method that is "PNP0501", and that is what the OS looks for. When it finds "PNP0501", it knows it's a 8250-like serial port.

Using Python to investigate EFI and ACPI

josh — Thu, 03 Sep 2015 18:36:25 +0000

> More worrying from a "bare-metal" perspective is Josh's comment about background tasks in EFI, I did not expect that.

EFI has some interrupt processing, including timers. It uses that for things like USB keyboards and drives, or networking support. Also take a look at the calls related to Task Priority Level (TPL).

In theory, all of those should stop when you ExitBootServices(); theoretically EFI drivers could keep doing things as part of runtime services, but they shouldn't, and I haven't seen that in practice.

Using Python to investigate EFI and ACPI

marcH — Thu, 03 Sep 2015 17:13:44 +0000

> except for very simple cases you want something multithreaded or at least reacting to several different events.

"Very simple cases" is all I had in mind. Hardware has become so cheap that dealing with the complexity and unpredictability of a scheduler and preemption is not always worth it. See Arduino as a good and successful example.

For reacting to different events something like select()/poll() / or any kind of non-blocking event loop does the job. Even Java can do stuff like this (not for real-time but for scalability)

This reminds me of this (also successful) product I used to work on. It permanently hogs/hogged (some) CPU cores thanks to Linux' SCHED_FIFO and implements its own event loop with incredibly good real-time properties. This worked surprisingly well considering the kernel was not designed for this and caused almost no problem. I found only this one at the time: https://bugzilla.kernel.org/show_bug.cgi?id=16011

More worrying from a "bare-metal" perspective is Josh's comment about background tasks in EFI, I did not expect that.

Using Python to investigate EFI and ACPI

josh — Thu, 03 Sep 2015 15:04:25 +0000

Responded in that thread; using BITS to test QEMU would be awesome. Seems only fair; we often use QEMU to test BITS.

Using Python to investigate EFI and ACPI

lacos — Thu, 03 Sep 2015 09:18:46 +0000

This sounds very exciting. I posted an email with some virtualization background and some questions.

http://thread.gmane.org/gmane.comp.emulators.qemu/358997

Thank you!

Using Python to investigate EFI and ACPI

aleXXX — Thu, 03 Sep 2015 08:18:04 +0000

Being on the bare metal does not automatically make your application "hard real-time".
It removes sources of latency coming from the OS, but since there is no RTOS supporting the application, you still have no real-time guarantees.... I mean, except for very simple cases you want something multithreaded or at least reacting to several different events.
E.g. a main loop checking flags triggered from interrupts is not hard-real time.

Using Python to investigate EFI and ACPI

josh — Thu, 03 Sep 2015 05:38:42 +0000

> Games! Any last remaining doubt about EFI implementations being OSes is now cleared. DOS was considered an OS after all.

Absolutely. EFI has *significantly* more functionality than DOS ever did.

> "Hard real-time" applications could be another interesting use case for EFI?

The line between "EFI application" and "bare-metal operating system" is quite thin. The main distinction between the two seems to lie in if you call EFI services or implement your own drivers. So sure, you could implement a minimal OS that relied on EFI for some of its core drivers.

However, EFI does have some background processing that can interrupt you, above and beyond the possibility of SMI. You'd want to ExitBootServices() at a minimum, at which point you have to take over a few things.

Using Python to investigate EFI and ACPI

josh — Thu, 03 Sep 2015 05:33:05 +0000

> Nearly all the non disk related stuff is somewhere else, typically in ROM.

Or, increasingly towards the end of DOS's useful lifespan, in the application. DOS applications shipped graphics drivers, sound drivers, network stacks...

Using Python to investigate EFI and ACPI

butlerm — Thu, 03 Sep 2015 05:10:01 +0000

I wouldn't quite consider MS-DOS a computer operating system, but rather a disk operating system. The letter 'D' is in there for a reason, as with Apple DOS before it. Nearly all the non disk related stuff is somewhere else, typically in ROM.

Using Python to investigate EFI and ACPI

marcH — Thu, 03 Sep 2015 04:14:31 +0000

Games! Any last remaining doubt about EFI implementations being OSes is now cleared. DOS was considered an OS after all.

"Hard real-time" applications could be another interesting use case for EFI?

Using Python to investigate EFI and ACPI

josh — Thu, 03 Sep 2015 03:35:01 +0000

Thanks for a great summary, Jake!