QStor SATA/RAID v.96 for 2.6.9-rc2
PATCH 1/1 QStor SATA/RAID v.96 for 2.6.9-rc2
Here is round-two for the Pacific Digital QStor SATA/RAID driver.
Most of the original concerns have been addressed, and a few bugs fixed in the interim.
This driver does not share code (yet) with libata, due to the difficulty of doing so at present -- the vendor wants the same source code to be usable (eventually) on early 2.4.xx kernels which lack libata, and much of the existing libata code requires libata-specific data structures. We'll work on that later.
New in this version is a scsi_worker_thread, used to feed drive hotplug events back to the mid-layer. During testing we discovered that this is very unsafe to do from "normal" driver context, since the mid-layer promptly calls back into the driver in the same context, causing all kinds of locking issues and whatnot.
Feedback is appreciated, but please keep it civil, guys!
Cheers
Signature · 2 lines
Mark Lord (hdparm keeper & the original "Linux IDE Guy")
Okay, I missed one thing in the proof read.. these two lines (below) will be added to qstor.c, for use by the separate RAID management module.
EXPORT_SYMBOL(qs_del_raid); EXPORT_SYMBOL(qs_setup_raid);
Cheers
Signature · 2 lines
Mark Lord (hdparm keeper & the original "Linux IDE Guy")
Quoted 5 lines · Mark Lord
Okay, I missed one thing in the proof read.. these two lines (below) will be added to
qstor.c, for use by the separate RAID management module.EXPORT_SYMBOL(qs_del_raid); EXPORT_SYMBOL(qs_setup_raid);
Where is this seperate RAID management module? :)
Typically we do not add kernel hooks to non-public stuff...
Jeff
Quoted 4 lines · Jeff Garzik
Where is this seperate RAID management module? :)
Typically we do not add kernel hooks to non-public stuff...
It is still under development. The vendor will likely distribute it in source code form with the product installation disk, since it is likely to undergo far more frequent updates that the base kernel driver.
This allows them to decouple the portion not needed at boot-time, from the more difficult to change kernel code that has to be there to boot the system on RAID.
Cheers
Signature · 2 lines
Mark Lord (hdparm keeper & the original "Linux IDE Guy")
Quoted 8 lines · Mark Lord
Quoted 4 lines · Jeff Garzik
Where is this seperate RAID management module? :)
Typically we do not add kernel hooks to non-public stuff...
Quoted 8 lines
It is still under development. The vendor will likely distribute it in source code form with the product installation disk, since it is likely to undergo far more frequent updates that the base kernel driver.
This allows them to decouple the portion not needed at boot-time, from the more difficult to change kernel code that has to be there to boot the system on RAID.
Regardless, if the RAID code isn't in the kernel or otherwise posted somewhere publicly and GPL'd, the hooks are unlikely to be accepted.
Jeff