4 ms·

Taking one example... UEFI is supposed to replace BIOS, but that spec is a mess, and nobody gets it right. I don't have a solution to this problem to propose, o

Taking one example... UEFI is supposed to replace BIOS, but that spec is a mess, and nobody gets it right. I don't have a solution to this problem to propose, other than to say, if you're in the position to influence specs that effect the design of hardware, or are the result of hardware design, please push for the simplest solution to the problem every chance you get. That said, huge amounts of complexity are added to things in the name of backwards compatibility, which is something we generally want. In the case of the S3 sleep state, this is just sloppy decision making. Sure give us a new fancy, half sleep-like mode, but don't touch the suspend to ram, it's a feature that has value.

wahern 8y ago
I can't disagree with you. But regarding backwards compatibility, the simpler the standard, the easer it is to write an implementation, the more practical it is to simply start fresh every iteration. Considering how cheap and disposable hardware is becoming these days, the more obvious is the false economy of flexibility in the design. I don't do much traditional driver development (mostly USB related, at least when it comes to hardware). I know enough that dealing with the ARM ecosystem can be much more of a headache than in the PC world, for two reasons: diversity and more opaque specs. (Even if the PC stuff is proprietary, there's enough publicly leaked info to at least get started.) But ARM features are also often much simpler and straight-forward. If the documentation were always and completely freely available[1], then I think many developers would prefer dealing with ARM platforms than with PCs. You may be writing more drivers, but development would be more efficient and reliable and you could move on without having as much of a maintenance and bug-fix burden. It can be a worthwhile trade-off, and fits better with the open source model. [1] I spent months trying to sign an NDA and gain access to NXP's iMX53 Security Reference Manual. After repeated back-and-forth with two NXP resellers, Mouser and Digi-Key, I just gave up.[2] I've heard of lone developers getting access to the manual, but they must be more familiar with the process than I am. Now I'm pivoting and have decided to use seL4 on PC hardware rather than bother with the TrustZone and the iMX53 crypto hardware, even though the ARM route would have been easier but for the documentation issue. [2] I think it's NXP that kept dropping the ball, but I'm really not sure.
wtallis 8y ago
> UEFI is supposed to replace BIOS, but that spec is a mess, and nobody gets it right. The culprit isn't UEFI, it's ACPI. That mess predates UEFI. Most operating systems don't really try to use UEFI features beyond the ability to manipulate the bootloader settings, and that feature is almost always correctly implemented. But it's impossible to find a consumer system with bug-free ACPI tables.
floatboth 8y ago
Is it a mess? The UEFI spec is big, but most of it is not necessary to boot. The UEFI implementation in U-Boot is tiny, and yet is enough to boot (both from local storage and network) and have a text console. Most non-embedded board vendors do not reimplement UEFI. There's not much to get right or wrong. They just take AMI or whoever's private fork of TianoCore, tweak some settings and customize the GUI. (It is possible to screw up the GUI though: https://youtu.be/F-ndTMeRT3s https://youtu.be/F-ndTMeRT3s) As mentioned in other comments, it's ACPI that's really bad. Though at least it's a standard! On ARM, you typically have to have a driver for every. damn. power. controller. Thankfully, ACPI is now appearing on higher end ARM stuff (servers like ThunderX, workstations like Overdrive, hopefully the new Microsoft always-connected laptops?)
- rayiner 8y ago
  > Thankfully, ACPI is now appearing on higher end ARM stuff (servers like ThunderX, workstations like Overdrive, hopefully the new Microsoft always-connected laptops?) I can't believe anyone would be thankful about ACPI. Is there a machine with ACPI that isn't broken in some way? My brand new Lenovo, which multiple sites have crowned the "best" PC laptop, ships with a LTE card that can't properly power down, and causes PCI-E ASPM to be disabled. Even Microsoft has f--ked up power management repeatedly in the Surface line. Power management on PCs is such a disaster that it calls into question the very idea of doing power management for computers built out of mix-and-match components through standards like ACPI.
  - rektide 8y ago
    I dunno. I've worked with a bunch of different ARM chips and each one's workflow is "build a kernel, build an initrd, then use this magic tool to get our boot ROM to load it" and that's always been gross & dumb. I'm not necessarily cheery about ACPI in practice, but ACPI & UEFI in theory provide some kind of substrate to manage the platform, that's not just whatever the engineers are some shop cooked up this time.
    - floatboth 8y ago
rbanffy 8y ago
It would be easier if the specs were developed without the "help" of organizations that stand to gain nothing from complete interoperability and who are perfectly content with "works with Windows".

wahern 8y ago

I can't disagree with you. But regarding backwards compatibility, the simpler the standard, the easer it is to write an implementation, the more practical it is to simply start fresh every iteration. Considering how cheap and disposable hardware is becoming these days, the more obvious is the false economy of flexibility in the design. I don't do much traditional driver development (mostly USB related, at least when it comes to hardware). I know enough that dealing with the ARM ecosystem can be much more of a headache than in the PC world, for two reasons: diversity and more opaque specs. (Even if the PC stuff is proprietary, there's enough publicly leaked info to at least get started.) But ARM features are also often much simpler and straight-forward. If the documentation were always and completely freely available[1], then I think many developers would prefer dealing with ARM platforms than with PCs. You may be writing more drivers, but development would be more efficient and reliable and you could move on without having as much of a maintenance and bug-fix burden. It can be a worthwhile trade-off, and fits better with the open source model. [1] I spent months trying to sign an NDA and gain access to NXP's iMX53 Security Reference Manual. After repeated back-and-forth with two NXP resellers, Mouser and Digi-Key, I just gave up.[2] I've heard of lone developers getting access to the manual, but they must be more familiar with the process than I am. Now I'm pivoting and have decided to use seL4 on PC hardware rather than bother with the TrustZone and the iMX53 crypto hardware, even though the ARM route would have been easier but for the documentation issue. [2] I think it's NXP that kept dropping the ball, but I'm really not sure.

wtallis 8y ago

> UEFI is supposed to replace BIOS, but that spec is a mess, and nobody gets it right. The culprit isn't UEFI, it's ACPI. That mess predates UEFI. Most operating systems don't really try to use UEFI features beyond the ability to manipulate the bootloader settings, and that feature is almost always correctly implemented. But it's impossible to find a consumer system with bug-free ACPI tables.

floatboth 8y ago

Is it a mess? The UEFI spec is big, but most of it is not necessary to boot. The UEFI implementation in U-Boot is tiny, and yet is enough to boot (both from local storage and network) and have a text console. Most non-embedded board vendors do not reimplement UEFI. There's not much to get right or wrong. They just take AMI or whoever's private fork of TianoCore, tweak some settings and customize the GUI. (It is possible to screw up the GUI though: https://youtu.be/F-ndTMeRT3s https://youtu.be/F-ndTMeRT3s) As mentioned in other comments, it's ACPI that's really bad. Though at least it's a standard! On ARM, you typically have to have a driver for every. damn. power. controller. Thankfully, ACPI is now appearing on higher end ARM stuff (servers like ThunderX, workstations like Overdrive, hopefully the new Microsoft always-connected laptops?)

rayiner 8y ago
> Thankfully, ACPI is now appearing on higher end ARM stuff (servers like ThunderX, workstations like Overdrive, hopefully the new Microsoft always-connected laptops?) I can't believe anyone would be thankful about ACPI. Is there a machine with ACPI that isn't broken in some way? My brand new Lenovo, which multiple sites have crowned the "best" PC laptop, ships with a LTE card that can't properly power down, and causes PCI-E ASPM to be disabled. Even Microsoft has f--ked up power management repeatedly in the Surface line. Power management on PCs is such a disaster that it calls into question the very idea of doing power management for computers built out of mix-and-match components through standards like ACPI.
- rektide 8y ago
  I dunno. I've worked with a bunch of different ARM chips and each one's workflow is "build a kernel, build an initrd, then use this magic tool to get our boot ROM to load it" and that's always been gross & dumb. I'm not necessarily cheery about ACPI in practice, but ACPI & UEFI in theory provide some kind of substrate to manage the platform, that's not just whatever the engineers are some shop cooked up this time.
  - floatboth 8y ago

rbanffy 8y ago

It would be easier if the specs were developed without the "help" of organizations that stand to gain nothing from complete interoperability and who are perfectly content with "works with Windows".