more granular detection and control to disable/enable PCI-ATA devices

[Alexander Motin]

Hi.

On 04.06.2013 18:30, Larry Melia wrote:
> With you suggestions, I finally was able to get the override driver
> working-see
> https://github.com/FreeBSDonHyper-V/freebsd-snapshot/blob/hyperv-dev-ata-override/sys/dev/hyperv/stordisengage/hv_ata_pci_disengage.c.
> While it operates wonderfully, allowing our "enlightened" driver to
> improve performance, some versions of Hyper-V still use the native
> CD-ROM driver, because there is no "enlightened" support for it in the
> hypervisor. From my limited knowledge of the ATA drivers, it seems
> likely that the PCI-ATA driver be attached when a CD-ROM is detected,
> but lower-level drivers disabled (during a probe) when a hard drive is
> detected. On Hyper-V, therefore, a user would be able to configure a
> PCI/IDE virtual controller with two devices, the first device a hard
> disk and the second one a CD-ROM. The CD-ROM would operate via the
> native driver, whereas the hard disk would use the "enlightened" driver
> (to improve performance).  Is there an easy way to add more granular
> detection, disabling the native ATA driver(s) selectively for hard
> drives, while allowing CD-ROM devices to be natively attached? Any
> suggestions would be very much appreciated.

Unfortunately, CAM subsystem used for both ATA and SCSI stacks in 
FreeBSD 9.x and above is mostly unaware of "NewBus" infrastructure used 
for driver probe and attachment. That is why you can't replace driver 
for a single disk in the same way as you replaced driver for the whole 
controller. The highest level present in "NewBus" is ATA channel. So if 
disk and CD-ROM are always live on different channels, you can create 
dummy driver not for the whole controller (atapciX), but for single 
hardcoded ATA channel (ataX).

Another possible way is to make controller driver not dummy, making it 
mostly duplicating default one, but filtering out unwanted devices. That 
may look like overkill, but it is not necessary so, because ATA stack is 
quite modularized, and you probably don't need to implement all ATA 
functionality such as mode setting, etc. Only thing that should be 
different in your driver is a reset method -- never reporting ATA disks 
to upper layers, only ATAPI devices. You may find number of drivers for 
example in sys/dev/ata/chipsets.

The later way is definitely more complicated then just a few lines hack 
blocking CAM ada driver (ATA disk driver), but it still can be made 
modular and non-invasive.

-- 
Alexander Motin