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
--
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
--
Mark Lord
(hdparm keeper & the original "Linux IDE Guy")
Mark Lord wrote:
> 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
Jeff Garzik wrote:
>
> 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
--
Mark Lord
(hdparm keeper & the original "Linux IDE Guy")
Mark Lord wrote:
> Jeff Garzik wrote:
>
>>
>> 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.
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