Skip to contentSkip to conversation

3rd Party Device Drivers need sd.h

RFC David van Hoose 3 participants 3 messages Oct 17, 2003 SCSI

lore
Share & tools
lore
#0 lore raw

I have been working on modifying the SATA driver that I got from Promise to work under 2.6.0. However, there is a conflict since it needs sd.h. I looked and sd.h was merged into sd.c. What reasons were there for doing this, and what changes have to be made to 3rd party drivers to accomodate it? Please CC to me as I am not on this list.

Thank you,
David van Hoose

#1 lore raw
Quoted 5 lines · David van Hoose

I have been working on modifying the SATA driver that I got from Promise to work under 2.6.0. However, there is a conflict since it needs sd.h. I looked and sd.h was merged into sd.c. What reasons were there for doing this, and what changes have to be made to 3rd party drivers to accomodate it? Please CC to me as I am not on this list.

The bios_param call now passes a scsi_device and its capacity, rather than a scsi_disk, it is a cleaner interface. Exporting interfaces or data structures from sd to host drivers makes little sense.

Just delete the sd.h include, and then updating the bios_param function should get rid of the scsi_disk or Disk reference.

Does Jeff's SATA/libata driver cover the Promise hardware?

-- Patrick Mansfield

#2 lore raw
Quoted 1 line · Patrick Mansfield

Does Jeff's SATA/libata driver cover the Promise hardware?

Yes

Jeff