Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > alt.os.development > #18745 > unrolled thread

Re: [OSDev] How to switch to long mode in x86 CPUs?

Back to article view | Back to alt.os.development

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [OSDev] How to switch to long mode in x86 CPUs? cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-02 20:26 +0000
    Re: [OSDev] How to switch to long mode in x86 CPUs? scott@slp53.sl.home (Scott Lurndal) - 2025-03-02 21:29 +0000
      Re: [OSDev] How to switch to long mode in x86 CPUs? cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-03 00:48 +0000
        Re: [OSDev] How to switch to long mode in x86 CPUs? scott@slp53.sl.home (Scott Lurndal) - 2025-03-03 14:51 +0000
          Re: [OSDev] How to switch to long mode in x86 CPUs? cross@spitfire.i.gajendra.net (Dan Cross) - 2025-03-03 20:20 +0000

#18745 — Re: [OSDev] How to switch to long mode in x86 CPUs?

[Note: Following up to alt.os.development]

I think there's an interesting discussion to be had here, but I
think it would be best outside of comp.lang.c.  I wish there was
a comp.* group for this (bring back comp.os.research!) but
alt.os.development is probably closest.

In article <cU%wP.111376$_N6e.73667@fx17.iad>,
Scott Lurndal <slp53@pacbell.net> wrote:
>Salvador Mirzo <smirzo@example.com> writes:
>>[snip]
>>Would you elaborate or point out an article or book that could clarify
>>the ideas that have made you to make such remark?  Sounds interesting.
>
>When the BIOS (as was originally intended) controls all the I/O interfaces,
>it fundamentally limits access to new and experimental devices, and limits
>the ability to generationally improve the hardware (e.g. Compare NVMe driver
>interface with a legacy ISA device vis-a-vis the OS interface to the device).

It certainly means that, for example, an OS-provided filesystem
that can only access a storage device via the BIOS can't use
those devices.  These primitive early PC "operating systems"
didn't provide any real memory safety, or try to prevent
programs from accessing the hardware directly, bypassing the OS.
So in theory a user program could talk directly to the device,
but then it has to go implement a filesystem (or something
equivalent) itself, and every program that wants to use that
data has to know how to talk to that device.  That obviously
defeats the purpose of having the OS provide the abstraction.

>It requires the mainboard manufacturer that provides the BIOS include
>support for all new third-party hardware innovations.  Given the BIOS
>was orignally a ROM, such systems were extremely difficult to update
>and there was no way to accomodate new third-party hardware without
>bypassing the BIOS entirely.

+1e6

>The expansion ROM on PCI was an attempt to remedy this, but clearly
>falls short when supporting multiple hardware families (e.g. various
>RISC and CISC architectures) pushing the burden to support new
>or different operating systems upon the device hardware manufacturer;
>which either requires differnent SKUs for each generation of each
>supported processor family, a significant burden on the device hardware
>manufacturer.

I'm going to quibble with this one a little bit.

To my mind, modern firmware, including BIOS-like systems,
provides three fundamental facilities:

1. It provides an abstraction interface for systems software,
   both the traditional BIOS role, but also a way to decouple
   emulate legacy hardware interfaces so that hardware
   advances are decoupled from systems software.  Consider
   running DOS on a machine with a USB keyboard and mouse;
   "BIOS" gives me a way to emulate an AT or PS/2 keyboard.
   (Don't get me started on the dumpster fire that is SMM.)
2. It's a place to do all sorts of platform enablement.  For
   example, on modern x86 systems, firmware does DRAM timing
   training, IO bus enumeration and initial allocation and
   assignment of physical address space for MMIO, bridge
   assignment and configuration, etc.
3. It solves a necessary bootstrapping problem.  Often, an
   operating system is installed on some storage device that
   sits on some controller somewhere.  But in order to load the
   OS, I have to be able to initialize and drive the controller
   "enough" to be able to load the OS (or at least some kind of
   boot loader that knows to to load the OS).  Firmware that
   understands enough of the platform to do the bare minimum to
   drive hardware and load a more elaborate bootstrap let's me
   boot a real system.

Options ROMs were meant as part of the solution to last problem:
give the hardware enough smarts so that very simple code running
in a very constrained early boot environment could get something
from the device itself that lets the firmware drive the device
well enough to load more capable software from it.  With a
well-defined and sufficiently capable interface between the
option ROM and firmware, third-party hardware designed well
after a system was put in place can be used on that system,
provided the OS it uses has been updated so that it can drive
the new hardware.

I don't think this is a bad way to do things, to be honest;
interfaces are fundamental for isolation in software.  And the
way that OpenFirmware did it was actually pretty nice: provide
an interpreter for a sufficiently general language (FORTH) in
firmware, and store little programs in that language in ROM on
the device that let firmware drive the device enough to load a
real OS.  Pair firmware with a little bit of non-volatile
storage like battery-backed CMOS so that you can store a few
variables, and you're good to go.

But of course, the expression of the idea in UEFI has become a
bloated and insecure mess that creeped into everything, and you
can't really get rid of it, even once the OS is running.

>BIOS is a least-common-denominator hardware abstraction interface.

This times 100.  BIOS wasn't just there to bootstrap, it was
meant to be _the_ interface to the hardware, as you point out.
That was fine on the anemic Z80-based machines that CP/M ran on,
but it's awful once you want to do something more complex.

	- Dan C.

[toc] | [next] | [standalone]

#18746

cross@spitfire.i.gajendra.net (Dan Cross) writes:
>[Note: Following up to alt.os.development]
>
>I think there's an interesting discussion to be had here, but I
>think it would be best outside of comp.lang.c.  I wish there was
>a comp.* group for this (bring back comp.os.research!) but
>alt.os.development is probably closest.
>
>In article <cU%wP.111376$_N6e.73667@fx17.iad>,
>Scott Lurndal <slp53@pacbell.net> wrote:
>>Salvador Mirzo <smirzo@example.com> writes:
>>>[snip]
>>>Would you elaborate or point out an article or book that could clarify
>>>the ideas that have made you to make such remark?  Sounds interesting.
>>
>>When the BIOS (as was originally intended) controls all the I/O interfaces,
>>it fundamentally limits access to new and experimental devices, and limits
>>the ability to generationally improve the hardware (e.g. Compare NVMe driver
>>interface with a legacy ISA device vis-a-vis the OS interface to the device).
>
>It certainly means that, for example, an OS-provided filesystem
>that can only access a storage device via the BIOS can't use
>those devices.  These primitive early PC "operating systems"
>didn't provide any real memory safety, or try to prevent
>programs from accessing the hardware directly, bypassing the OS.
>So in theory a user program could talk directly to the device,
>but then it has to go implement a filesystem (or something
>equivalent) itself, and every program that wants to use that
>data has to know how to talk to that device.  That obviously
>defeats the purpose of having the OS provide the abstraction.
>
>>It requires the mainboard manufacturer that provides the BIOS include
>>support for all new third-party hardware innovations.  Given the BIOS
>>was orignally a ROM, such systems were extremely difficult to update
>>and there was no way to accomodate new third-party hardware without
>>bypassing the BIOS entirely.
>
>+1e6
>
>>The expansion ROM on PCI was an attempt to remedy this, but clearly
>>falls short when supporting multiple hardware families (e.g. various
>>RISC and CISC architectures) pushing the burden to support new
>>or different operating systems upon the device hardware manufacturer;
>>which either requires differnent SKUs for each generation of each
>>supported processor family, a significant burden on the device hardware
>>manufacturer.
>
>I'm going to quibble with this one a little bit.
>
>To my mind, modern firmware, including BIOS-like systems,
>provides three fundamental facilities:
>
>1. It provides an abstraction interface for systems software,
>   both the traditional BIOS role, but also a way to decouple
>   emulate legacy hardware interfaces so that hardware
>   advances are decoupled from systems software.  Consider
>   running DOS on a machine with a USB keyboard and mouse;
>   "BIOS" gives me a way to emulate an AT or PS/2 keyboard.
>   (Don't get me started on the dumpster fire that is SMM.)

While traditionally it was the case, the firmware component
(such as it was in the 8088/8086 systems) was a minor portion
of the BIOS and not generally exposed as an API.  The idea
of a BIOS as a respository of OS driver functionality is the
idea that I contest.

>2. It's a place to do all sorts of platform enablement.  For
>   example, on modern x86 systems, firmware does DRAM timing
>   training, IO bus enumeration and initial allocation and
>   assignment of physical address space for MMIO, bridge
>   assignment and configuration, etc.

This, however, is not generally done via option ROM; consider
a BIOS as having two components - the hardware initialization
function and the part that abstracts the device hardware
from the operating software.  I would term the former as
firmware, and the later as the BIOS conceptually.

Most modern high-end processors have several small management
cores (tiny x86 for intel/amd, cortex-m for other vendors)
that handle the huge amount of hardware setup required before
the UEFI software gains control.   From on-chip ROM initializing
serial peripheral interface controllers and loading initialization
firmware into on-chip sram, to initializing all the internal
address routing functionality (to support programmable bars,
for instance), initializing on-chip SERDES, ethernet MACs,
setting clock speeds, enabling clocks, handling trusted boot,
etc.  All happens before the first core leaves the reset
state. (Unlike x86, which when it left reset started fetching
from a direct-attached ROM on the LPC bus).

>3. It solves a necessary bootstrapping problem.  Often, an
>   operating system is installed on some storage device that
>   sits on some controller somewhere.  But in order to load the
>   OS, I have to be able to initialize and drive the controller
>   "enough" to be able to load the OS (or at least some kind of
>   boot loader that knows to to load the OS).  Firmware that
>   understands enough of the platform to do the bare minimum to
>   drive hardware and load a more elaborate bootstrap let's me
>   boot a real system.
>
>Options ROMs were meant as part of the solution to last problem:
>give the hardware enough smarts so that very simple code running
>in a very constrained early boot environment could get something
>from the device itself that lets the firmware drive the device
>well enough to load more capable software from it. 

Their primary use was in network interface cards, primarily
to support PXE boot, in my experience.

[toc] | [prev] | [next] | [standalone]

#18747

In article <e54xP.27616$3pn5.5162@fx44.iad>,
Scott Lurndal <slp53@pacbell.net> wrote:
>cross@spitfire.i.gajendra.net (Dan Cross) writes:
>In article <cU%wP.111376$_N6e.73667@fx17.iad>,
>>Scott Lurndal <slp53@pacbell.net> wrote:
>>>[snip]
>>>The expansion ROM on PCI was an attempt to remedy this, but clearly
>>>falls short when supporting multiple hardware families (e.g. various
>>>RISC and CISC architectures) pushing the burden to support new
>>>or different operating systems upon the device hardware manufacturer;
>>>which either requires differnent SKUs for each generation of each
>>>supported processor family, a significant burden on the device hardware
>>>manufacturer.
>>
>>I'm going to quibble with this one a little bit.
>>
>>To my mind, modern firmware, including BIOS-like systems,
>>provides three fundamental facilities:
>>
>>1. It provides an abstraction interface for systems software,
>>   both the traditional BIOS role, but also a way to decouple
>>   emulate legacy hardware interfaces so that hardware
>>   advances are decoupled from systems software.  Consider
>>   running DOS on a machine with a USB keyboard and mouse;
>>   "BIOS" gives me a way to emulate an AT or PS/2 keyboard.
>>   (Don't get me started on the dumpster fire that is SMM.)
>
>While traditionally it was the case, the firmware component
>(such as it was in the 8088/8086 systems) was a minor portion
>of the BIOS and not generally exposed as an API.  The idea
>of a BIOS as a respository of OS driver functionality is the
>idea that I contest.

I am in total agreement with you here.  To be clear, I wasn't
trying to refer to traditional BIOSes here so much as address
the bit about option ROMs.

>>2. It's a place to do all sorts of platform enablement.  For
>>   example, on modern x86 systems, firmware does DRAM timing
>>   training, IO bus enumeration and initial allocation and
>>   assignment of physical address space for MMIO, bridge
>>   assignment and configuration, etc.
>
>This, however, is not generally done via option ROM; consider
>a BIOS as having two components - the hardware initialization
>function and the part that abstracts the device hardware
>from the operating software.  I would term the former as
>firmware, and the later as the BIOS conceptually.

Yes.  My point was prefatory to discussing why we have option
ROMs and where they fit into the larger ecosystem, and the role
played by firmware on a modern system.  To state it succinctly,
I believe that firmware still plays a useful role, beyond the
IO functions of the traditional BIOS.  Apologies if that wasn't
sufficiently clear in my earlier post.

>Most modern high-end processors have several small management
>cores (tiny x86 for intel/amd, cortex-m for other vendors)

AMD uses Cortex-A, actually.  I'm pretty sure the PSP is an A5
class part.  As for the other hidden cores?  Who knows.  :-(

>that handle the huge amount of hardware setup required before
>the UEFI software gains control.   From on-chip ROM initializing
>serial peripheral interface controllers and loading initialization
>firmware into on-chip sram, to initializing all the internal
>address routing functionality (to support programmable bars,
>for instance), initializing on-chip SERDES, ethernet MACs,
>setting clock speeds, enabling clocks, handling trusted boot,
>etc.  All happens before the first core leaves the reset
>state. (Unlike x86, which when it left reset started fetching
>from a direct-attached ROM on the LPC bus).

I liken booting a modern CPU to starting up a container ship.
You may initiate the sequence by pushing a button, but it's not
like the enormous 2-story tall cylinders on the marine engines
just start firing right away.  Rather, you probably spin up an
electric motor to start a (much smaller) diesel engine that
begins the compression cycle until you've established sufficient
pressure that you can start the big ones, etc.

But at least for AMD, much of the initialization you mention
above really is done on x86.

Initializing the data fabric, CCX init, programming bus speeds,
etc, is all done by AGESA (or whatever replaces it, if you're
not using AGESA; we do that in the host OS at work and have no
AGESA or UEFI on our machines).  Actual PCIe training is done
by another of the hidden cores in the SoC complex (one that you
interact with indirectly via the SMU in Milan and earlier; via
MPIO in Genoa and later), but using data structures set up by
software running on x86.

I've always set Ethernet MACs in device drivers, but I guess if
you are trying to boot over Ethernet before x86 comes online
you're back to the bootstrapping problem I mentioned below.

>>3. It solves a necessary bootstrapping problem.  Often, an
>>   operating system is installed on some storage device that
>>   sits on some controller somewhere.  But in order to load the
>>   OS, I have to be able to initialize and drive the controller
>>   "enough" to be able to load the OS (or at least some kind of
>>   boot loader that knows to to load the OS).  Firmware that
>>   understands enough of the platform to do the bare minimum to
>>   drive hardware and load a more elaborate bootstrap let's me
>>   boot a real system.
>>
>>Options ROMs were meant as part of the solution to last problem:
>>give the hardware enough smarts so that very simple code running
>>in a very constrained early boot environment could get something
>>from the device itself that lets the firmware drive the device
>>well enough to load more capable software from it. 
>
>Their primary use was in network interface cards, primarily
>to support PXE boot, in my experience.

Sure, usually poorly and buggily.  :-)  We had a bunch of dev
boxes in a little cluster that I convinced to boot into iPXE
from USB flash drives; each one would boot a kernel specific to
that machine.  So to boot a new test kernel on one of them, you
just copied the kernel to some well-known file name and issued
a command to reset that machine (I built a little
remote-controlled solid-state switch thing using optocouplers,
a programmable LED driver, and a little 8-bit microcontroller,
then wired those in parallel with the machine's reset and power
switches).  The UARTs were all connected to a machine somewhere
with USB adapters; so the computer would boot come back, boot
into iPXE from the USB device, then load and run your new
kernel while you monitored the UART remotely.  It was a really
nice setup.

But I can still remember buying PCI SCSI adapters in the mid-90s
(perhaps from Adaptec?) that had OpenFirmware ROMs so that you
could boot from them on SPARC.  At one point, we had higher
hopes for third-party peripherals, I guess.  Now it seems like
most storage controllers are just another IP on the platform.

	- Dan C.

[toc] | [prev] | [next] | [standalone]

#18748

cross@spitfire.i.gajendra.net (Dan Cross) writes:
>In article <e54xP.27616$3pn5.5162@fx44.iad>,
>Scott Lurndal <slp53@pacbell.net> wrote:
>>cross@spitfire.i.gajendra.net (Dan Cross) writes:
>>In article <cU%wP.111376$_N6e.73667@fx17.iad>,
 <snip>
>
>>Most modern high-end processors have several small management
>>cores (tiny x86 for intel/amd, cortex-m for other vendors)
>
>AMD uses Cortex-A, actually.  I'm pretty sure the PSP is an A5
>class part.  As for the other hidden cores?  Who knows.  :-(\

Ah, thanks.  I've been out of the AMD world for a decade now,
building ARM64-based SoCs.

<snip>
>
>But at least for AMD, much of the initialization you mention
>above really is done on x86.
>
>Initializing the data fabric, CCX init, programming bus speeds,
>etc, is all done by AGESA (or whatever replaces it, if you're
>not using AGESA; we do that in the host OS at work and have no
>AGESA or UEFI on our machines).  Actual PCIe training is done
>by another of the hidden cores in the SoC complex (one that you
>interact with indirectly via the SMU in Milan and earlier; via
>MPIO in Genoa and later), but using data structures set up by
>software running on x86.

Ah, yes, I do recall AGESA - although when we were building
AMD systems, we contracted with Supermicro to do the BIOS;
AMD open-sourced AGESA just after we (3Leaf Systems) shut down.

>
>I've always set Ethernet MACs in device drivers, but I guess if
>you are trying to boot over Ethernet before x86 comes online
>you're back to the bootstrapping problem I mentioned below.

Sure, even on our SoCs, much of the ethernet MAC configuration
is done in the driver.   The parts between the MAC and the
port (assigning SERDES lanes to PCI controllers (x1, x4, x8),
initializing the SERDES, assigning MAC address, etc.) are
done by the firmware.

Plus, as you note, the firmware may have a TCP/IP stack
that requires MAC initialization to support PXE.


>>>
>>>Options ROMs were meant as part of the solution to last problem:
>>>give the hardware enough smarts so that very simple code running
>>>in a very constrained early boot environment could get something
>>>from the device itself that lets the firmware drive the device
>>>well enough to load more capable software from it. 
>>
>>Their primary use was in network interface cards, primarily
>>to support PXE boot, in my experience.
>
>Sure, usually poorly and buggily.  :-) 

Indeed.

> We had a bunch of dev
>boxes in a little cluster that I convinced to boot into iPXE
>from USB flash drives; each one would boot a kernel specific to
>that machine.  So to boot a new test kernel on one of them, you
>just copied the kernel to some well-known file name and issued
>a command to reset that machine (I built a little
>remote-controlled solid-state switch thing using optocouplers,
>a programmable LED driver, and a little 8-bit microcontroller,
>then wired those in parallel with the machine's reset and power
>switches).  The UARTs were all connected to a machine somewhere
>with USB adapters; so the computer would boot come back, boot
>into iPXE from the USB device, then load and run your new
>kernel while you monitored the UART remotely.  It was a really
>nice setup.
>
>But I can still remember buying PCI SCSI adapters in the mid-90s
>(perhaps from Adaptec?) that had OpenFirmware ROMs so that you
>could boot from them on SPARC.

What was missing was a standard driver interface for SCSI
similar to the later  AHCI for SATA (and UHCI/EHCI/xHCI for
USB).   Even those standard driver interfaces often require
firmware initialization to enable (and sometimes fully support).

>  At one point, we had higher
>hopes for third-party peripherals, I guess.  Now it seems like
>most storage controllers are just another IP on the platform.

Yup, and most new device classes have standardized driver interfaces
(e.g. NVMe).

[toc] | [prev] | [next] | [standalone]

#18749

In article <YljxP.120702$_N6e.64289@fx17.iad>,
Scott Lurndal <slp53@pacbell.net> wrote:
>cross@spitfire.i.gajendra.net (Dan Cross) writes:
>>In article <e54xP.27616$3pn5.5162@fx44.iad>,
>>Scott Lurndal <slp53@pacbell.net> wrote:
>>>cross@spitfire.i.gajendra.net (Dan Cross) writes:
>>>In article <cU%wP.111376$_N6e.73667@fx17.iad>,
> <snip>
>>
>>>Most modern high-end processors have several small management
>>>cores (tiny x86 for intel/amd, cortex-m for other vendors)
>>
>>AMD uses Cortex-A, actually.  I'm pretty sure the PSP is an A5
>>class part.  As for the other hidden cores?  Who knows.  :-(\
>
>Ah, thanks.  I've been out of the AMD world for a decade now,
>building ARM64-based SoCs.

Consider me jealous.  :-)

><snip>
>>
>>But at least for AMD, much of the initialization you mention
>>above really is done on x86.
>>
>>Initializing the data fabric, CCX init, programming bus speeds,
>>etc, is all done by AGESA (or whatever replaces it, if you're
>>not using AGESA; we do that in the host OS at work and have no
>>AGESA or UEFI on our machines).  Actual PCIe training is done
>>by another of the hidden cores in the SoC complex (one that you
>>interact with indirectly via the SMU in Milan and earlier; via
>>MPIO in Genoa and later), but using data structures set up by
>>software running on x86.
>
>Ah, yes, I do recall AGESA - although when we were building
>AMD systems, we contracted with Supermicro to do the BIOS;
>AMD open-sourced AGESA just after we (3Leaf Systems) shut down.

Yeah.  It was open for a brief, shining moment, and then they
brought it back in and closed the source.  ISVs can get access
to it under NDA, but it's only useful as a reference, really.
You _can_ build an actual firmware image by overlayering it onto
with, but it requires a lot of tinkering to get something that
will actually boot a real OS.

The PoR, as I understand it, is to release 6th gen Zen (Venice
maybe?) with UEFI built on openSIL, which is sort of like open
source AGESA.  I think they'll use EDKII for the UEFI bits.
https://github.com/openSIL/openSIL

>>I've always set Ethernet MACs in device drivers, but I guess if
>>you are trying to boot over Ethernet before x86 comes online
>>you're back to the bootstrapping problem I mentioned below.
>
>Sure, even on our SoCs, much of the ethernet MAC configuration
>is done in the driver.   The parts between the MAC and the
>port (assigning SERDES lanes to PCI controllers (x1, x4, x8),
>initializing the SERDES, assigning MAC address, etc.) are
>done by the firmware.

Yeah.  AGESA does that on AMD.  Well, it sets some data in RAM
and DMAs it over to either the SMU or MPIO which use it to
configure DXIO.

E.g.,
https://github.com/openSIL/openSIL/blob/3000c3227a015d649298ce5dabc804905e243060/xUSL/Mpio/Common/MpioInitFlow.c#L508

>Plus, as you note, the firmware may have a TCP/IP stack
>that requires MAC initialization to support PXE.

I feel like this is where Ron Minnich's LinuxBoot stuff works
well.  Replace the UEFI DXE layer with a copy of Linux and a
small userspace written in a type- and memory-safe language.
You've got a real IP stack and can do DHCP and use TCP to load
and kexec your real OS.

>>>>Options ROMs were meant as part of the solution to last problem:
>>>>give the hardware enough smarts so that very simple code running
>>>>in a very constrained early boot environment could get something
>>>>from the device itself that lets the firmware drive the device
>>>>well enough to load more capable software from it. 
>>>
>>>Their primary use was in network interface cards, primarily
>>>to support PXE boot, in my experience.
>>
>>Sure, usually poorly and buggily.  :-) 
>
>Indeed.
>
>> We had a bunch of dev
>>boxes in a little cluster that I convinced to boot into iPXE
>>from USB flash drives; each one would boot a kernel specific to
>>that machine.  So to boot a new test kernel on one of them, you
>>just copied the kernel to some well-known file name and issued
>>a command to reset that machine (I built a little
>>remote-controlled solid-state switch thing using optocouplers,
>>a programmable LED driver, and a little 8-bit microcontroller,
>>then wired those in parallel with the machine's reset and power
>>switches).  The UARTs were all connected to a machine somewhere
>>with USB adapters; so the computer would boot come back, boot
>>into iPXE from the USB device, then load and run your new
>>kernel while you monitored the UART remotely.  It was a really
>>nice setup.
>>
>>But I can still remember buying PCI SCSI adapters in the mid-90s
>>(perhaps from Adaptec?) that had OpenFirmware ROMs so that you
>>could boot from them on SPARC.
>
>What was missing was a standard driver interface for SCSI
>similar to the later  AHCI for SATA (and UHCI/EHCI/xHCI for
>USB).   Even those standard driver interfaces often require
>firmware initialization to enable (and sometimes fully support).

Yeah.  It's like the SCSI folks had a good standard for the
peripheral side, and PCIe gives us a good IO architecture on the
host side, but they totally missed a standardized controller
interface.  That, and cost, hurt adoption.

>>  At one point, we had higher
>>hopes for third-party peripherals, I guess.  Now it seems like
>>most storage controllers are just another IP on the platform.
>
>Yup, and most new device classes have standardized driver interfaces
>(e.g. NVMe).

Yeah, that's a really good point.

	- Dan C.

[toc] | [prev] | [standalone]

Back to top | Article view | alt.os.development

csiph-web