Comment by oneplane | Hacker News Reader

Comment by oneplane | Hacker News Reader

Like the article explains, it makes sense if you can do this and reduce the amount of now 'legacy' interfaces.

We used to do IDE emulation over SATA for a while, then we got AHCI over SATA and AHCI over other fabrics. Makes sense to stop carrying all the legacy loads all the time. For people that really need it for compatibility reasons we still have the vortex86 style solutions that generally fit the bill as well as integrated controllers that do PCIe-to-PCI bridging with a classic IDE controller attached to that converted PCI bus. Options will stay, but cutting legacy by default makes sense to me. Except UART of course, that can stay forever.

Edit: I stand corrected, AHCI (like the name implies: Advanced Host Controller Interface) is for the communication up to the controller. Essentially the ATA commands continue to be sent to the drive but the difference is between commanding the controller over IDE or AHCI modes. This is also why the controller then needs to know about the drive, where NVMe doesn't need to know about the drive because the ATA protocol is no longer needed to be understood by the controller (as posted here elsewhere).

> then we got AHCI over SATA

AHCI is the native SATA mode, AFAIK explicit mentions of AHCI are mostly over non-SATA interfaces (usually m.2, because an m.2 SSD can be SATA, AHCI over PCIe, or NVMe).

AHCI is the driver protocol used for communication between the CPU/OS and the SATA host bus adapter. It stops there, and nothing traveling over the SATA cable can be correctly called AHCI.

You can have fully standard SATA communication happening between a SATA drive and a SATA-compatible SAS HBA that uses a proprietary non-AHCI driver interface, and from the drive's end of the SATA cable this situation is completely indistinguishable from using a normal SATA HBA.

Likewise, you can have AHCI communication to a PCIe SSD and the OS will think it's talking to a single-port SATA HBA, with the peculiarity that sustained transfers in excess of 6Gbps are possible.

>It stops there, and nothing traveling over the SATA cable can be correctly called AHCI.

Informally, a lot of BIOSes (another informality there!) would give you the choice back in the day between IDE or AHCI when it came to communicating with the drive.

I think this is where most of the confusion came from.

That choice was largely about which drivers your OS included. The IDE compatibility mode meant you could use an older OS that didn't include an AHCI driver. The toggle didn't actually change anything about the communication between the chipset and the drive, but did change how the OS saw the storage controller built-in to the chipset on the motherboard. The newer host controller interface was required to make use of some newer features on drives, because IDE compatibility mode had no way to expose that functionality.

(Later, a third option appeared for proprietary RAID modes that required vendor-specific drivers, and that eventually led to more insanity and user misunderstandings when NVMe came onto the scene.)

This wasn't about how the SATA controller talks to the drives, but about how the SATA controller is presented to the operating system. The IDE/legacy setting was useful at the time because Window XP lacked AHCI drives on the install media. This compatibility setting simplified the installation of Windows XP on newer hardware which was very common in the DIY space at the time it was introduced. Afterward you could install AHCI drivers and switch to AHCI mode for improved performance (iirc AHCI was required for NCQ).

> AFAIK explicit mentions of AHCI are mostly over non-SATA interfaces

No, I'm no expert in this at all, but every motherboard I've had has had an AHCI/IDE mode toggle for its SATA ports.

(Maybe the same thing is sometimes framed as 'legacy' mode vs. not or something? Just not that I've seen.)

On Intel motherboards, it was a switch between initializing the SATA controller into PIIX4 interface or AHCI interface.

SATA is still IDE, just with different physical layer.

>Except UART of course, that can stay forever.

Same for 3.5mm TRS for analog connections :D

This never really got "replaced" though. All the new connectors are for digital connections.

There's not much new for analog, which is probably the way it should be.

USB-C has a mode called Audio Adapter Accessory Mode. In this D+ and D- become right and left analog audio output, respectively, and SBU1 becomes analog microphone input.

Here's a reference design from TI showing how one might implement it on a device where you want to be able to switch between using your USB-C connector for data devices and for analog audio devices [1].

[1] https://www.ti.com/lit/ug/tidub66/tidub66.pdf

There won't be much new for analog until something lower level is found.

> All the new connectors are for digital connections.

USB-C headphones might disagree with you, as the other comment has pointed out (USB-C supports analog audio on data pins in order to create the one-connector-to-rule-them-all).

The new MacBook Pro even has automatic phantom power

Nice. I feel like that used to be common for PC microphone ports that were separate jacks, but IIRC it was at a much lower voltage than the 48V professional phantom power.

I actually don't see much point in these changes besides "new and shiny" trendchasing with perhaps a bit of planned obolescence thrown in. NVMe is a massive complexity increase for little gain. Looking at all the bugs in various NVMe implementations and drivers (many of which are "worked around" by detecting specific devices) is enough to scare you from trusting them for storage.

NVMe is certainly not more complex than either AHCI or SAS from a driver or hardware interface standpoint. And I've written drivers for all three that run in production today. Now maybe the controller design is more difficult - I wouldn't know - but there are several vendors that sell NVMe controllers out there so it can't be all that bad.

And as noted in the other comments, this is about simplifying support for things like connectors, LEDs, expanders, and software in data centers where they're mixing NVMe SSDs and HDDs today. It's just simpler to have fewer parts and software differences.

Reply on news.ycombinator.com