5 ms·

ACPI is a huge part of the reason that linux works at all on x86, and in many cases is as popular as it is. If it acted more like arm boards where pretty much n

ACPI is a huge part of the reason that linux works at all on x86, and in many cases is as popular as it is. If it acted more like arm boards where pretty much nothing works right, no one would use it for general purpose computing. There are literally hundreds and hundreds of drivers for PMICs, clock dividers, GPIO pin muxing/etc for the hundred or so boards that sorta work, and each one needs customization that takes months/years every time something gets tweaked on the board/etc. ACPI allows random x86 board vendors to literally have hundreds of products themselves that not only boot linux, but a pile of other OS's because they aren't wasting their time writing drivers for every single board and voltage regulator. So, call it shitty, but understand that its the reason you can boot a single linux image on everything from an atomicPi, to HP superdome flex, and the thousands of desktops/etc being customized by people in their bedrooms. Its also largely the reason why linux works on 20 year old PC's that no one is actually testing on anymore. The alternative is a monoculture where the HW is basically provided by a single vendor that doesn't change much and provides a half dozen supported configurations. I would point to the zseries here because that is effectively how it works, but it also has a huge hw/firmware abstract machine that allows IBM to change the underlying HW details without having to rewrite all this low value garbage.

tenebrisalietum 5y ago
> There are literally hundreds and hundreds of drivers for PMICs and voltage dividors, GPIO pin muxing/etc for the hundred or so boards that sorta work, and each one needs customization that takes months/years everytime something gets tweaked on the board/etc. There's literally tens of thousands of devices for the PC platform and Linux has no problem supporting them if the hardware can be documented. Why can't the vendor document that instead of hiding this stuff behind opaque binary blobs that can have security vulnerabilities? Whether this is ARM or x86 doesn't matter. > ACPI OTOH allows random x86 board vendors to literally have hundreds of products themselves that not only boot linux, but a pile of other OS's because they aren't wasting their time writing drivers for every single board and voltage regulator. I'm parsing this as "ACPI OTOH allows random x86 board vendors to develop shitty hardware, cut corners on documenting it, and not care as long as Microsoft OS's boot on it." > they aren't wasting their time writing drivers for every single board and voltage regulator. Document the damn registers and hardware interfaces and then someone out there will write it for them. > Its also largely the reason why linux works on 20 year old PC's that no one is actually testing on anymore. Well Linux still supports hardware that predates ACPI, like floppy drives, so this is making a connection where there is none. > The alternative is a monoculture where the HW is basically provided by a single vendor that doesn't change much and provides a half dozen supported configurations. Wrong. Before ACPI, for example, there were many chipset vendors--Opti, VIA, etc. ACPI didn't kill these off but there wasn't a monoculture before ACPI. > I would point to the zseries here So ... do we want an IBM-mainframe like monoculture where you have to depend on IBM when the hardware changes? > allows IBM to change the underlying HW details The job of abstracting the hardware details is the operating system and operating system drivers. Literally that's 50% of the reason why you have an OS in the first place is to abstract I/O into things like open(), read(), write() or other interfaces that are portable because of underlying drivers. If the hardware is so different that existing I/O calls can't handle it, you need to develop new ones - that's what happened with Berkely sockets - NICs are not block or character devices. If the drivers are open source then they are bug-correctable and useable even well after the hardware manufacturer goes away. Embedding that in closed-source platform-firmware makes you dependent on that platform manufacturer. A strong contributor to the Wintel monopoly.
- StillBored 5y ago
  Wrong. Before ACPI, for example, there were many chipset vendors--Opti, VIA, etc. ACPI didn't kill these off but there wasn't a monoculture before ACPI. That is where your wrong, x86 PC's had BIOS and APM which also provided minimal platform abstractions. But there was a monoculture, you either provided PC/AT HW and BIOS compatibility or your x86 didn't work. There were HW "standards" for everything, be that CGA/EGA/VGA, or IDE controllers. Yes, you might make your own video card, but its absolutely supported those standards. Similarly with chipsets, there were closed source early boot firmware, but by the time the MBR was being loaded it looked like a 1980's PC/AT. As far as there being enough driver developers to further fill the kernel with all these drivers belies a fundamental misunderstanding of how complex even those arm machines are behind the scenes, even the ones that work likely have huge stacks of binary code running places that aren't visible to linux/DT. You need only look at some of the open or reverse engineered arm boards to see that. the RK3399 specs were published, what 4 years ago at this point, and there are still rk3399 fixes landing. Should it take 5+ years from the release of a piece of hardware before linux can boot and work reliably on it? edit: See https://en.wikipedia.org/wiki/Option_ROM https://en.wikipedia.org/wiki/Option_ROM for where all that binary code used to hide in the 1990's when you plugged in random "vga" boards and storage controllers.
  - tenebrisalietum 5y ago
    The original idea behind BIOS was to provide drivers (and a firmware interface to them) so CP/M could run and also read the first disk block into memory so CP/M could load. This was awesome when your platform consisted of an 8-bit CPU, a serial port or two, a printer port or two, a disk drive or two, and a text-based video display. ROM and BIOS is a poor place for drivers if - your system has any notion of plug-and-play at all - your system has expansion slots and arbitrary people you don't control might develop hardware for it. and these two things above are desirable if you want a free-ish computing platform not monopolized by one company. Hardware interfaces are not the same as the firmware gunk ACPI foists upon you. Hardware interfaces are simply a way for the CPU to talk to a device outside of the system, but it doesn't result in the CPU running unknown code behind your back. A CPU that's cordoned off behind a peripheral interface running closed-source code is fine - where that's not fine is on the same CPU that's running my OS kernel. > Should it take 5+ years from the release of a piece of hardware before linux can boot and work reliably on it? I mean if the hardware manufacturer won't document their devices it's something they bring upon themselves. Embracing the open source community here would have substantial benefits unless something like market segmentation is taking place. Option ROMs? Yeah, those are BIOS extensions - your OS isn't dealing with those ROMs once the BIOS has booted the OS unless it's a CP/M era operating system - like actual DOS. Except for the modesetting - but that's just as much bullshit as ACPI. Document the damn registers that do the modesetting change so we don't have to thunk back into 16-bit mode just to change the screen resolution.

tenebrisalietum 5y ago

> There are literally hundreds and hundreds of drivers for PMICs and voltage dividors, GPIO pin muxing/etc for the hundred or so boards that sorta work, and each one needs customization that takes months/years everytime something gets tweaked on the board/etc. There's literally tens of thousands of devices for the PC platform and Linux has no problem supporting them if the hardware can be documented. Why can't the vendor document that instead of hiding this stuff behind opaque binary blobs that can have security vulnerabilities? Whether this is ARM or x86 doesn't matter. > ACPI OTOH allows random x86 board vendors to literally have hundreds of products themselves that not only boot linux, but a pile of other OS's because they aren't wasting their time writing drivers for every single board and voltage regulator. I'm parsing this as "ACPI OTOH allows random x86 board vendors to develop shitty hardware, cut corners on documenting it, and not care as long as Microsoft OS's boot on it." > they aren't wasting their time writing drivers for every single board and voltage regulator. Document the damn registers and hardware interfaces and then someone out there will write it for them. > Its also largely the reason why linux works on 20 year old PC's that no one is actually testing on anymore. Well Linux still supports hardware that predates ACPI, like floppy drives, so this is making a connection where there is none. > The alternative is a monoculture where the HW is basically provided by a single vendor that doesn't change much and provides a half dozen supported configurations. Wrong. Before ACPI, for example, there were many chipset vendors--Opti, VIA, etc. ACPI didn't kill these off but there wasn't a monoculture before ACPI. > I would point to the zseries here So ... do we want an IBM-mainframe like monoculture where you have to depend on IBM when the hardware changes? > allows IBM to change the underlying HW details The job of abstracting the hardware details is the operating system and operating system drivers. Literally that's 50% of the reason why you have an OS in the first place is to abstract I/O into things like open(), read(), write() or other interfaces that are portable because of underlying drivers. If the hardware is so different that existing I/O calls can't handle it, you need to develop new ones - that's what happened with Berkely sockets - NICs are not block or character devices. If the drivers are open source then they are bug-correctable and useable even well after the hardware manufacturer goes away. Embedding that in closed-source platform-firmware makes you dependent on that platform manufacturer. A strong contributor to the Wintel monopoly.

StillBored 5y ago
Wrong. Before ACPI, for example, there were many chipset vendors--Opti, VIA, etc. ACPI didn't kill these off but there wasn't a monoculture before ACPI. That is where your wrong, x86 PC's had BIOS and APM which also provided minimal platform abstractions. But there was a monoculture, you either provided PC/AT HW and BIOS compatibility or your x86 didn't work. There were HW "standards" for everything, be that CGA/EGA/VGA, or IDE controllers. Yes, you might make your own video card, but its absolutely supported those standards. Similarly with chipsets, there were closed source early boot firmware, but by the time the MBR was being loaded it looked like a 1980's PC/AT. As far as there being enough driver developers to further fill the kernel with all these drivers belies a fundamental misunderstanding of how complex even those arm machines are behind the scenes, even the ones that work likely have huge stacks of binary code running places that aren't visible to linux/DT. You need only look at some of the open or reverse engineered arm boards to see that. the RK3399 specs were published, what 4 years ago at this point, and there are still rk3399 fixes landing. Should it take 5+ years from the release of a piece of hardware before linux can boot and work reliably on it? edit: See https://en.wikipedia.org/wiki/Option_ROM https://en.wikipedia.org/wiki/Option_ROM for where all that binary code used to hide in the 1990's when you plugged in random "vga" boards and storage controllers.
- tenebrisalietum 5y ago
  The original idea behind BIOS was to provide drivers (and a firmware interface to them) so CP/M could run and also read the first disk block into memory so CP/M could load. This was awesome when your platform consisted of an 8-bit CPU, a serial port or two, a printer port or two, a disk drive or two, and a text-based video display. ROM and BIOS is a poor place for drivers if - your system has any notion of plug-and-play at all - your system has expansion slots and arbitrary people you don't control might develop hardware for it. and these two things above are desirable if you want a free-ish computing platform not monopolized by one company. Hardware interfaces are not the same as the firmware gunk ACPI foists upon you. Hardware interfaces are simply a way for the CPU to talk to a device outside of the system, but it doesn't result in the CPU running unknown code behind your back. A CPU that's cordoned off behind a peripheral interface running closed-source code is fine - where that's not fine is on the same CPU that's running my OS kernel. > Should it take 5+ years from the release of a piece of hardware before linux can boot and work reliably on it? I mean if the hardware manufacturer won't document their devices it's something they bring upon themselves. Embracing the open source community here would have substantial benefits unless something like market segmentation is taking place. Option ROMs? Yeah, those are BIOS extensions - your OS isn't dealing with those ROMs once the BIOS has booted the OS unless it's a CP/M era operating system - like actual DOS. Except for the modesetting - but that's just as much bullshit as ACPI. Document the damn registers that do the modesetting change so we don't have to thunk back into 16-bit mode just to change the screen resolution.