Post AbMfWDvFu2hbu9CW2K by landley@mstdn.jp
(DIR) More posts by landley@mstdn.jp
(DIR) Post #AbLgtus5DqILjentdQ by mjg59@nondeterministic.computer
2023-11-01T02:38:35Z
0 likes, 1 repeats
"Why does ACPI exist" in the beforetimes power management on x86 was done by jumping to an opaque BIOS entry point and hoping it would do the right thing. It frequently didn't. Failed to program your graphics card exactly the way the BIOS expected? Hurrah! Data corruption for you. ACPI made the reasonable decision that, well, maybe it should be up to the OS to set state and be able to recover it. But how should the OS deal with state that's fundamentally device specific?
(DIR) Post #AbLhBK9QUCI53uDTyC by mjg59@nondeterministic.computer
2023-11-01T02:41:17Z
0 likes, 0 repeats
One way to do that would be to have the OS know about the device specific details. Unfortunately that means you can't ship the computer until you modify every single OS you want to support and get new releases out there. This, uh, was not an option the PC industry seriously considered. The alternative is that you ship something that abstracts the details of the specific hardware. This is what ACPI does, and it's also what things like Device Tree do.
(DIR) Post #AbLhKPnypkFrCiWJqS by mjg59@nondeterministic.computer
2023-11-01T02:43:29Z
0 likes, 0 repeats
The main distinction between Device Tree and ACPI is that Device Tree is purely a description of the hardware that exists, and so still requires the OS to know what's possible - if you add a new type of power controller, for instance, you need to add a driver for that to the OS before you can express that via Device Tree. ACPI decided to include an interpreted language to allow vendors to expose functionality to the OS without the OS needing to know about the underlying hardware.
(DIR) Post #AbLhSrQi0ezXCHf8K0 by mjg59@nondeterministic.computer
2023-11-01T02:44:52Z
0 likes, 0 repeats
So, for instance, ACPI allows you to associate a device with function to power down that device. That function may, when executed, trigger a bunch of register accesses to a piece of hardware otherwise not exposed to the OS, and that hardware may then cut the power rail to the device to power it down entirely. And that can be done without the OS having to know anything about the control hardware.
(DIR) Post #AbLhdvBsMqjg2vzyRU by mjg59@nondeterministic.computer
2023-11-01T02:46:08Z
0 likes, 0 repeats
How is this better than just calling into the firmware to do it? Because the fact that ACPI declares that it's going to access these registers means the OS can figure out that it shouldn't, because it might otherwise collide with what the firmware is doing. With APM we had no visibility into that - if the OS tried to touch the hardware at the same time APM did, boom, almost impossible to debug failures
(DIR) Post #AbLhu9E7wsHgDEmycS by yuubi@furry.engineer
2023-11-01T02:48:50Z
0 likes, 0 repeats
@mjg59 that's making the open firmware song play in my head.TTTO flintstones openingfirmwareopen firmwareit's appropriate technology
(DIR) Post #AbLi5JkJBBCU1RARqy by mjg59@nondeterministic.computer
2023-11-01T02:51:09Z
0 likes, 0 repeats
(This is why various hardware monitoring drivers refuse to load by default on Linux - the firmware declares that it's going to touch those registers itself, so Linux decides not to in order to avoid race conditions and potential hardware damage. In many cases the firmware offers a collaborative interface to obtain the same data, and a driver can be written to get that (https://bugzilla.kernel.org/show_bug.cgi?id=204807#c37 discusses this for a specific board)
(DIR) Post #AbLiMitquWxQxUvo24 by mjg59@nondeterministic.computer
2023-11-01T02:54:13Z
0 likes, 0 repeats
Unfortunately ACPI doesn't entirely remove opaque firmware from the equation - ACPI methods can still trigger System Management Mode, which is basically a fancy way to say "Your computer stops running your OS, does something else for a while, and you have no idea what". This has all the same issues that APM did, in that if the hardware isn't in exactly the state the firmware expects, bad things can happen.
(DIR) Post #AbLiexQXdaX3E6urrs by mjg59@nondeterministic.computer
2023-11-01T02:58:24Z
0 likes, 0 repeats
Historically there were a bunch of ACPI-related issues because the spec didn't define every single possible scenario and also there was no conformance suite (eg, should the interpreter be multi-threaded? Not defined by spec, but influences whether a specific implementation will work or not!). These days overall compatibility is pretty solid and the vast majority of systems work just fine, but we do still have some issues that are largely associated with System Management Mode.
(DIR) Post #AbLj74oZlQPwFOZAoq by klausman@mas.to
2023-11-01T03:03:24Z
0 likes, 0 repeats
@mjg59 Not to mention that many ACPI issues were/are caused by the motherboard-side implementation of ACPI being buggy, incomplete or self-contradictory. One thing that ACPI decidedly isn't: simple.
(DIR) Post #AbLjF0mSe9403JMQpU by mjg59@nondeterministic.computer
2023-11-01T03:03:55Z
0 likes, 0 repeats
One example is a recent Lenovo one, where the firmware appears to try to poke the NVME drive on resume. There's some indication that this is intended to deal with transparently unlocking self-encrypting drives on resume, but it seems to do so without taking IOMMU configuration into account and so things explode. It's kind of understandable why a vendor would implement something like this, but it's also kind of understandable that doing so without OS cooperation may end badly.
(DIR) Post #AbLjeBit6GixEGh7Ts by mjg59@nondeterministic.computer
2023-11-01T03:09:24Z
0 likes, 0 repeats
This isn't something that ACPI enabled - in the absence of ACPI firmware vendors would just be doing this unilaterally with even less OS involvement and we'd probably have even more of these issues. Ideally we'd "simply" have hardware that didn't support transitioning back to opaque code, but we don't (ARM has basically the same issue with TrustZone)
(DIR) Post #AbLkAA1WxBJ3E2ezi4 by mjg59@nondeterministic.computer
2023-11-01T03:15:20Z
0 likes, 1 repeats
By and large ACPI has been a net improvement in Linux compatibility on x86 systems. It certainly didn't remove the "Everything is Windows" mentality that many vendors have, but it meant we largely only needed to ensure that Linux behaved the same way as Windows in a finite number of ways rather than in every single hardware driver, and so the chances that a new machine will work out of the box are much greater than they were in the pre-ACPI period
(DIR) Post #AbLko9rKz4j2Iaxs8G by irenes@mastodon.social
2023-11-01T03:22:25Z
0 likes, 0 repeats
@mjg59 thanks for that, it's difficult to know what to think about the relative merits of it without this kind of experience
(DIR) Post #AbLlSDNnIr2ioIFLwu by ciggysmokebringer@kolektiva.social
2023-11-01T03:29:17Z
0 likes, 0 repeats
@mjg59 Love how you wrote this, lol.
(DIR) Post #AbLmqBUq4HfdrcXEv2 by mjg59@nondeterministic.computer
2023-11-01T03:45:13Z
0 likes, 0 repeats
(The alternative of teaching the kernel about every piece of hardware it should run on? We've seen that in the ARM world. Most code simply never reaches mainline, and most users are stuck running ancient kernels as a result. Imagine every x86 device vendor shipping their own kernel optimised for their hardware, and now imagine how well that works out given the quality of their firmware. Does that really seem better to you?)
(DIR) Post #AbLp57cowYLM6qWFHc by neversphere@ioc.exchange
2023-11-01T04:10:12Z
0 likes, 0 repeats
@mjg59 is there a decent primer on ACPI?
(DIR) Post #AbLpblh3VQM9e64Csy by artemist@social.mildlyfunctional.gay
2023-11-01T04:16:11Z
0 likes, 0 repeats
@mjg59 The funny thing is that many of the ARM devices that support ACPI boot Linux with device trees. I'm not sure quite why, I'm guessing undocumented extensions or something.I've found device trees fine enough for embedded devices but really wish more stuff supported ACPI if you would even think about using a distro other than buildroot or yocto
(DIR) Post #AbLqFoe3x0JkNqlNRo by mjg59@nondeterministic.computer
2023-11-01T04:23:45Z
0 likes, 0 repeats
@neversphere Honestly version 1 of the spec? It's a reasonable size compared to later versions and covers most of what's still relevant today
(DIR) Post #AbLrrKO6zjfFV6klCC by mjg59@nondeterministic.computer
2023-11-01T04:41:09Z
0 likes, 0 repeats
@jwp @neversphere Yeah ARM+SBSA in theory brings ARM into the same space, but SBSA-conforming devices make up a tiny amount of deployed ARM
(DIR) Post #AbLsEfthBni6s5euoq by mjg59@nondeterministic.computer
2023-11-01T04:45:52Z
0 likes, 0 repeats
@jwp @neversphere SBSA has Opinions like what sort of interrupt controller you have and a bunch of mobile stuff just doesn't conform to those opinions (Windows on ARM deals with this by using a vendor-supplied HAL)
(DIR) Post #AbLtbuFi5Eyq0Wb6jg by arj@social.tchncs.de
2023-11-01T05:00:33Z
0 likes, 0 repeats
@mjg59 every now and then benh would start banging on about adding a bytecode feature to devicetree. Never quite got around to implementing it though
(DIR) Post #AbLu6zmdZLJC8fp75s by ncommander@social.restless.systems
2023-11-01T05:06:45Z
0 likes, 0 repeats
@mjg59 What frustrates me is the sheer number of vendors that didn't see this as a problem (or saw it as a feature), combined with ARM refusing to try and even address this problem when AArch64 is released.It's difficult to say that ARM is a viable competitor in non-embedded spaces when you can't say that you'll be able to install an update six months down the line (and this is sadly not even a hypothetical ...)
(DIR) Post #AbLuEDxRGg8u7uK480 by mjg59@nondeterministic.computer
2023-11-01T05:08:01Z
0 likes, 0 repeats
@ncommander tbf SBSA does do that in the server space (and for exactly this reason)
(DIR) Post #AbLvCXdZEGUQXJn0Oe by ncommander@social.restless.systems
2023-11-01T05:19:02Z
0 likes, 0 repeats
@mjg59 Yeah, but versions of what the SBSA would become existed even prior to AArch64. How much shipping silicon actually has UEFI in firmware and is SBSA ready?By and large, the only time I've seen ARM64 work like x86 on Apple stuff :/It's 2023, and I feel like the ecosystem has barely moved in the last seven years. It really made me feel like the several years I spent working on this problem was utterly poitless.
(DIR) Post #AbLwRq5b0UEU3vl3Ng by mwhudson@mastodon.social
2023-11-01T05:32:29Z
0 likes, 0 repeats
@mjg59 well another difference is that (practically speaking) you have to ship your device tree as part of the OS right?
(DIR) Post #AbLwkzbtpeMp5r071s by mjg59@nondeterministic.computer
2023-11-01T05:36:15Z
0 likes, 0 repeats
@mwhudson there's no inherent reason not to have a standard way to read that from the firmware or first-stage bootloader (effectively equivalent)
(DIR) Post #AbLwtdR7dwECve54e8 by mwhudson@mastodon.social
2023-11-01T05:37:30Z
0 likes, 0 repeats
@mjg59 well sure but in practice the device tree format changes, doesn't it? I guess it may settle down eventually...
(DIR) Post #AbLx2mqa1YUeinLuXw by stark@mastodon.mit.edu
2023-11-01T05:38:51Z
0 likes, 0 repeats
@mjg59 thanks. ACPI was always a mystery to me.But one thing I still don't get. The kernel needs a driver to talk to every device and that driver needs to know how to do everything else. Why is turning the device on and off so uniquely tricky that it would be a problem to do that in the driver too?
(DIR) Post #AbLy9yiQOb0rVoWyR6 by mjg59@nondeterministic.computer
2023-11-01T05:52:13Z
0 likes, 0 repeats
@stark That kind of thing ends up being *very* platform dependent. Say you have a GPU - the GPU driver has no idea how the power line to the GPU is controlled, because that's up to how it was wired up in the specific machine, and the control mechanism is likely also hardware-specific (is it controlled via the embedded controller? Is there some other power controller that needs to be spoken to? That sort of thing)
(DIR) Post #AbM0u4cMz0Pz2yo39M by mjg59@nondeterministic.computer
2023-11-01T06:22:31Z
0 likes, 0 repeats
@josh @stark Intel tried https://en.wikipedia.org/wiki/Simple_Firmware_Interface and basically nobody was interested
(DIR) Post #AbM14hZf00oilPbgv2 by mjg59@nondeterministic.computer
2023-11-01T06:24:55Z
0 likes, 0 repeats
@josh @stark And, well, the fundamental problem is still that you need to identify all possible scenarios people might reasonably want to implement in advance, and it's clear the industry isn't interested in that
(DIR) Post #AbM1EMiZOgrKyVNlT6 by mjg59@nondeterministic.computer
2023-11-01T06:25:30Z
0 likes, 0 repeats
@eevee Therapy has all kinds of useful side-effects
(DIR) Post #AbM2od7hymjAEbzrQu by josh@social.joshtriplett.org
2023-11-01T06:40:21.716553Z
0 likes, 0 repeats
Sure, but that happened well after vendors had the option of ACPI and could just say "this new thing sucks, where do we shove all the proprietary custom stuff" and ignore it.Not saying it's politically feasible to push standardized interfaces with no custom code, just that the result seems wildly better.(Then again, at this point I'd just take "you can't get certified for Windows if you use SMI, ever".)
(DIR) Post #AbM2oduH4DZkfEie8G by mjg59@nondeterministic.computer
2023-11-01T06:44:16Z
0 likes, 0 repeats
@josh @stark Yeah, but it feels more likely that in the face of "You can't do this in ACPI" we'd just have more "We're doing this in SMM instead", and I don't think that's better. SMM is a fundamental part of the x86 security model (how do you manage authenticated flash access otherwise?) so removing it entirely seems complicated? And honestly I suspect that it would be too big a change for even Microsoft to impose on the industry.
(DIR) Post #AbM3LX2xap3swdSsFs by azonenberg@ioc.exchange
2023-11-01T06:49:50Z
0 likes, 0 repeats
@mjg59 What I don't understand is why all of this functionality is implemented on the CPU at all, rather than on the EC/BMC.(and then have the EC/BMC expose a standardized, abstracted API to the OS for things like voltage/temperature sensors)Power management also seems like the kind of thing that makes more sense to have been architected as an out of band feature that software was unaware of except for giving high level directives to the EC.
(DIR) Post #AbM3U1tyl40mxOJdvE by mjg59@nondeterministic.computer
2023-11-01T06:51:04Z
0 likes, 0 repeats
@azonenberg It being entirely in the EC would be basically equivalent to ACPI except we'd have less insight into what's going on behind the scenes
(DIR) Post #AbM3i6lJU6nk5JyY7M by azonenberg@ioc.exchange
2023-11-01T06:54:21Z
0 likes, 0 repeats
@mjg59 I'm thinking more about things like SMM (and ME, and even UEFI).What does SMM do that the EC couldn't do better?All of the hardware I design these days has a MCU that does management stuff (sometimes two, one really low level one for power/reset sequencing and one that comes up later to do everything else) and then talks to an FPGA that does most of the work of the board.The FPGA doesn't care about polling sensors or controlling fan speeds or anything else that's needed to make the system work. It just lives off in its own temperature-controlled world and does its thing, and has a SPI interface to the MCU when it needs something.
(DIR) Post #AbM3qTUwpv5iurJJAG by mjg59@nondeterministic.computer
2023-11-01T06:55:56Z
0 likes, 0 repeats
@azonenberg The EC doesn't have access to the CPU's buses, SMM does.
(DIR) Post #AbM47JjwN1PVZgM1Tc by azonenberg@ioc.exchange
2023-11-01T06:58:36Z
0 likes, 0 repeats
@mjg59 Which buses in particular? PCIe etc I assume, not SMBus / eSPI which it definitely does?And that's an issue with how we currently have systems architected. Not a fundamental limitation if this were 30 years ago and we were figuring out how to add things like power management to the i386 platform with ISA buses etc.I'm wondering why it made sense to go this way in the first place.
(DIR) Post #AbM4GcMqU0mPx8zE5Q by mjg59@nondeterministic.computer
2023-11-01T07:00:03Z
0 likes, 0 repeats
@azonenberg Vendors use SMM to do things like directly access PCI devices on resume, which is kind of entirely counter to the entire point of ACPI but still
(DIR) Post #AbM4SvxPTUOCBUxhVg by azonenberg@ioc.exchange
2023-11-01T07:02:39Z
0 likes, 0 repeats
@mjg59 I'm not asking how it's currently (ab)used :)It just seems like power management is the kind of thing that makes sense to do in a super low power coprocessor that's running all the time, independent of the CPU and OS (and incapable of touching end user data or main RAM - exclusively control plane), and cares about all of these low level board specific details.Ideally that coprocessor would also do things like poke the necessary registers in the northbridge to initialize the RAM controller so the OS bootloader could come up out of reset with fully working DRAM like all of my FPGA-based systems do, but that's probably wishful thinking :)
(DIR) Post #AbM65B9LXNmWGHLUTQ by azonenberg@ioc.exchange
2023-11-01T07:05:34Z
0 likes, 0 repeats
@mjg59 Well OK *ideally* the RAM controller would just be an RTL state machine that knows how to parse the SPD and make the RAM work without any software ever being in the loop.But it seems that ship sailed years ago.
(DIR) Post #AbM65ByOTacAobEG2a by azonenberg@ioc.exchange
2023-11-01T07:19:11Z
0 likes, 0 repeats
@mjg59 In general it seems like we have this criscrossing of low level management stuff (reset, power management, etc) and high level stuff (business logic of the hardware) that are living in commingled register spaces on the same bus, but that's an engineering decision.There's no reason why it couldn't be separated. For example, on most of the MCUs I work on, the registers for reset, clock enable, and power enable to various peripherals are completely independent (totally separate address range) from the registers for that peripheral. They might not even be on the same AMBA segment.I can totally imagine standardization of all power management over SMBus or eSPI by the EC, for example, with the PCIe side only used by the OS.As far as I can see it's an an architectural decision (one I'm not a fan of, due to making privilege separation and compartmentalization more difficult), not a fundamental limitation.
(DIR) Post #AbM65CoVLqIZQDbsGW by mjg59@nondeterministic.computer
2023-11-01T07:20:55Z
0 likes, 0 repeats
@azonenberg In that model, how does the firmware transparently manage self-encrypting drive unlock? I agree that there's a strong argument that it *shouldn't*, but otherwise it's something that you don't get to launch without OS support and that's not how the market works.
(DIR) Post #AbM6PCSOO3Og6inixE by azonenberg@ioc.exchange
2023-11-01T07:23:41Z
0 likes, 0 repeats
@mjg59 I'm also a bit skeptical of the benefits of SEDs vs OS-managed FDE. Always seemed like a gimmick to me (especially since it's implemented in black-box firmware).Treat the drive as an untrusted remote server that you write bits to and hope the same bits later come back. Assume anyone else can read those bits and encrypt anything you don't want the world to see.
(DIR) Post #AbM6bAemuCCC02J6I4 by azonenberg@ioc.exchange
2023-11-01T07:25:03Z
0 likes, 0 repeats
@mjg59 If the drive wants to use AES internally as a whitening function to provide desirable statistical properties to your data for media wear leveling, simultaneous switching output control, forward error correction? Totally fine.But don't trust the drive to keep your secrets.
(DIR) Post #AbM6bDW2HByerlEeZ6 by mjg59@nondeterministic.computer
2023-11-01T07:26:00Z
0 likes, 0 repeats
@azonenberg Look I fundamentally agree but that's not what we have
(DIR) Post #AbM9gsXJUQfbOqDxpY by dascandy42@mastodon.social
2023-11-01T07:56:58Z
0 likes, 0 repeats
@azonenberg @mjg59 Didn't we have PCIe config space versus BAR space for the OS management versus usage? What happened to that?
(DIR) Post #AbM9gtbxUdyojXPBi4 by mjg59@nondeterministic.computer
2023-11-01T08:00:54Z
0 likes, 0 repeats
@dascandy42 @azonenberg There's no way to speak to either without going via the CPU
(DIR) Post #AbMAoOVD8fumWQO8vo by krono@toot.berlin
2023-11-01T08:12:40Z
0 likes, 0 repeats
@mjg59 Nice Writeup!
(DIR) Post #AbMDj1uc09U0sFP3po by f4grx@chaos.social
2023-11-01T08:46:26Z
0 likes, 0 repeats
@mjg59 thank you for this acpi suppary, it taught me a lot of things.
(DIR) Post #AbMeqk4txWBHTFvtzM by pascaldragon@metalhead.club
2023-11-01T13:49:24Z
0 likes, 0 repeats
@mjg59 one issue with ACPI - though it's an issue of specific vendors instead of ACPI in general - is that on Qualcomm ARM Laptops Qualcomm decided to move quite some logic into their Windows drivers instead of ACPI due to the Windows ASL parser being buggy compared to ACPICA which makes running alternative operating systems using purely ACPI on these laptops a bit annoying as one needs to reverse engineer the drivers to discover the interactions between devices 🙄
(DIR) Post #AbMfGgW7oxP1xL2LfU by etchedpixels@mastodon.social
2023-11-01T13:52:02Z
0 likes, 0 repeats
@mjg59 An appopriate subject for halloween. Unfortunately ACPI now mostly seems to consist of parsing a lot of over complicated crap in order to discover you are supposed to write a 1 to an io port which turns out to be fake and causes an SMI trap which then does exactly what the APM approach of "jump here and pray" did.
(DIR) Post #AbMfWDvFu2hbu9CW2K by landley@mstdn.jp
2023-11-01T13:57:37Z
0 likes, 0 repeats
@mjg59 And if device tree hadn't been GPL preventing even BSD from adopting it, we might not have wound up with ACPI on arm. As I complained about back in the day... https://www.uwsg.indiana.edu/hypermail/linux/kernel/1505.3/00292.html
(DIR) Post #AbMgBo6OIDPbzEEoJE by jvert@techhub.social
2023-11-01T14:04:52Z
0 likes, 0 repeats
@mjg59 There is another alternative where Linux supports a driver ABI that is stable between kernel releases. Like Windows does. This has a set of different problems, but it is an alternative. You could say ACPI is that ABI.
(DIR) Post #AbMkWTZOE4uGCkufa4 by jgalowicz@functional.cafe
2023-11-01T14:52:50Z
0 likes, 0 repeats
@mjg59 It's super frustrating that while there is an ACPI standard ASL to AML compiler, HW vendors typically use the microsoft ASL compiler and then produce code that doesn't work nicely with the open source implementations.
(DIR) Post #AbMwbl6xdLVZVStvyi by penguin42@mastodon.org.uk
2023-11-01T17:10:49Z
0 likes, 0 repeats
@azonenberg @mjg59 But don't forget how complex the set of hardware is and how configurable it is for a given system; unlike a mostly fixed SoC. You could have hundreds of PCIe devices, each with their own power management firmware, wakeups from all over; and the OS is asking you to juggle where/when it can use the limited power and cooling.
(DIR) Post #AbNEge3z40q8GozLA8 by hyc@mastodon.social
2023-11-01T20:21:18Z
0 likes, 0 repeats
@klausman @mjg59 and there were still plenty of issues where the ACPI expects the OS to be some flavor of Windows, e.g. "if win95 do X elseif win2k do Y" and does nothing on Linux, so some feature just doesn't work. Typically we'd fix these by dumping the DSDT and rewriting it, but nowadays dynamically loadable DSDTs are deprecated even though those types of problems are just as prevalent as ever.
(DIR) Post #AbNEgeyhf8D56jWdZQ by mjg59@nondeterministic.computer
2023-11-01T20:31:54Z
0 likes, 0 repeats
@hyc @klausman And the answer is just to claim to be Windows, because Windows has an established contract with the firmware in a way that Linux never has
(DIR) Post #AbNFjHDQZEHcETDxh2 by hyc@mastodon.social
2023-11-01T20:39:39Z
0 likes, 0 repeats
@mjg59 @klausman That's the stock answer but it's inadequate. You have to know to claim to be a specific version of Windows, otherwise you still get breakage.
(DIR) Post #AbNH3KENAMe5KVn2v2 by mjg59@nondeterministic.computer
2023-11-01T20:58:32Z
0 likes, 0 repeats
@hyc @klausman You claim to be whatever is the latest version of Windows whose behaviour you've attempted to model
(DIR) Post #AbNOWL4LpMpI0UstKS by bsdphk@fosstodon.org
2023-11-01T22:22:02Z
0 likes, 0 repeats
@mjg59 The worst part of ACPI is that they invented at stupid crappy unique language for it.The world would be a better place if they had just picked an already existing scripting language like Tcl, Lua or even Python...
(DIR) Post #AbNRxtZfwgrKhjMrKK by mjg59@nondeterministic.computer
2023-11-01T23:00:34Z
0 likes, 0 repeats
@bsdphk you want to put one of those in-kernel?
(DIR) Post #AbRPTN0943ThiWuAmu by bsdphk@fosstodon.org
2023-11-03T20:51:30Z
0 likes, 0 repeats
@mjg59 Sure.
(DIR) Post #AbT1nihO5u5MDcDorA by JosuGZ@fosstodon.org
2023-11-04T15:34:53Z
0 likes, 0 repeats
@mjg59 With the move to ARM laptops, are we fucked?
(DIR) Post #Acohumjjx5ZHCRkBou by Conan_Kudo@fosstodon.org
2023-12-15T00:28:01Z
0 likes, 0 repeats
@mjg59 @jwp @neversphere Ultimately, SBSA was too late. If it had been introduced early enough when vendors were not used to the pain, there would have been more drive to adapt to it and adopt it. But by the time it was settled and being promoted, everyone was used to the problems of the current model.It doesn't help that Arm doesn't think it should be pushing for stuff like this either...