Garrett: Why ACPI?

Posted Nov 3, 2023 16:02 UTC (Fri) by Wol (subscriber, #4433)
In reply to: Garrett: Why ACPI? by pizza
Parent article: Garrett: Why ACPI?

Throw in the OS probing for devices ... if you don't want to have to recompile your OS for every different hardware variant out there, the OS needs to try asking the hardware.

I've done that. It's NOT NICE. And you know the old Unix error message? "Your printer is on fire"? It wasn't unknown for an innocent OS probe to let the magic smoke out of some peripheral or other - one only has to look back at X destroying VDUs by setting the wrong mode line...

Cheers,
Wol

Garrett: Why ACPI?

Posted Nov 3, 2023 19:47 UTC (Fri) by pizza (subscriber, #46) [Link] (1 responses)

> I've done that. It's NOT NICE.

ACtually, that depends. When the hardware is designed to be safely pluggable & probable (eg USB, PCI[e], and other self-describing interconnects), probing works just fine. But trying to probe for things that weren't designed with that in mind... can lead to some nastiness.

> "Your printer is on fire"? It wasn't unknown for an innocent OS probe to let the magic smoke out of some peripheral or other

That wasn't due to probing; it was a tongue-in-cheek interpretation of (very limited) status signals that the line printer could report.

(See https://en.wikipedia.org/wiki/Lp0_on_fire )

> one only has to look back at X destroying VDUs by setting the wrong mode line...

That was due to the user supplying a display configuration that the monitor couldn't handle rather than probing, and was no different than someone manually picking a bogus resolution+refresh rate in $Other_OS. Eventually, VGA monitors gained a standard mechanism to report their capabilities (via DDC & EDID) and that remains in use today.

Garrett: Why ACPI?

Posted Nov 4, 2023 17:52 UTC (Sat) by Wol (subscriber, #4433) [Link]

> > I've done that. It's NOT NICE.

> ACtually, that depends. When the hardware is designed to be safely pluggable & probable (eg USB, PCI[e], and other self-describing interconnects), probing works just fine. But trying to probe for things that weren't designed with that in mind... can lead to some nastiness.

I had it easy. I was just using a terminal emulator. With clueless lusers. So I had the emulator wIntegrate, some real physical Pr1me PT100s, and PT250s, Wyse, Adds3E, ...

And as I say, clueless lusers who just refused to know what was going on. Fortunately, I discovered that <ESC>E (iirc) was the standard "ask the terminal to send an answerback" code. I don't think it's universal, I was lucky that it was on all the physical terminals, and I could program the emulator to respond.

So I coded the login shell to send <ESC>E, listened for the response, and set the appropriate terminal type. Still broke regularly, but at least I wasn't repeatedly fielding calls from users who'd selected the wrong terminal type and wondered why their screens were all messed up.

(Likewise, the shell chose the user's default printer based on their department, and as much automation as I could manage to try and suppress all the grief lusers cause ... :-)

You don't want to go there, if you can avoid it ...

Cheers,
Wol