Something kind of like that was done for x86 with NCR's SCSI host adapters. NCR provided a traditional driver for each supported OS (DOS, Windows, OS/2, Novell Netware, SCO Unix) but that driver didn't know anything about the actual SCSI host adapter hardware. I'll call this the "generic driver".
The host adapter ROM contained a driver for the specific hardware on that card, written in a way that did not make any assumptions about the operating system. (Actually, there were two drivers in the ROM. A 16-bit driver for DOS and Windows 3.x and a 32-bit driver for the others). I'll call the drivers from ROM the "hardware drivers".
The generic driver would find the ROM. The ROM had a header that contained information about the hardware driver. That included pointers to various entry points in the hardware driver, including an init routine. The generic driver would call the init routine, and one of the things it gave the init routine was a table of entry points in the generic driver that the hardware driver could use to do things like allocate and free memory, register interrupt handlers, set up DMA operations, and things like that.
My recollection is that the 16-bit hardware drivers were position-independent code that could be run out of the ROM directly, or copied to RAM where it might run faster. The 32-bit code was not position independent, so the generic driver had to copy it to memory and the fix it up, which it could do because the 32-bit driver in ROM was essentially the .o output of the C compiler used to build it so had everything needed in order to move it around.
Once the hardware driver was initialized and running, the interface between it and the generic driver for actually doing SCSI commands was based on a draft version of the SCSI CAM specification. We [1] were on the CAM committee, and proposed including our ROM-based hardware driver approach as part of the standard, but most other committee members didn't think being able to swap host adapters without having to change OS drivers was useful enough.
[1] "We" == the consulting company that designed and implemented the aforementioned stuff for NCR. I was the lead architect and lead programmer for the project.
Comments
Something kind of like that was done for x86 with NCR's SCSI host adapters. NCR provided a traditional driver for each supported OS (DOS, Windows, OS/2, Novell Netware, SCO Unix) but that driver didn't know anything about the actual SCSI host adapter hardware. I'll call this the "generic driver".
The host adapter ROM contained a driver for the specific hardware on that card, written in a way that did not make any assumptions about the operating system. (Actually, there were two drivers in the ROM. A 16-bit driver for DOS and Windows 3.x and a 32-bit driver for the others). I'll call the drivers from ROM the "hardware drivers".
The generic driver would find the ROM. The ROM had a header that contained information about the hardware driver. That included pointers to various entry points in the hardware driver, including an init routine. The generic driver would call the init routine, and one of the things it gave the init routine was a table of entry points in the generic driver that the hardware driver could use to do things like allocate and free memory, register interrupt handlers, set up DMA operations, and things like that.
My recollection is that the 16-bit hardware drivers were position-independent code that could be run out of the ROM directly, or copied to RAM where it might run faster. The 32-bit code was not position independent, so the generic driver had to copy it to memory and the fix it up, which it could do because the 32-bit driver in ROM was essentially the .o output of the C compiler used to build it so had everything needed in order to move it around.
Once the hardware driver was initialized and running, the interface between it and the generic driver for actually doing SCSI commands was based on a draft version of the SCSI CAM specification. We [1] were on the CAM committee, and proposed including our ROM-based hardware driver approach as part of the standard, but most other committee members didn't think being able to swap host adapters without having to change OS drivers was useful enough.
[1] "We" == the consulting company that designed and implemented the aforementioned stuff for NCR. I was the lead architect and lead programmer for the project.