Darrick J. Wong wrote:
Jeff Garzik wrote:
I disagree completely with this approach.
You don't need a table of hooks for the case where libata is disabled in
.config. Thus, it's only useful for the case where libsas is loaded as
a module, but libata is not.
Indeed, I misunderstood what James Bottomley wanted, so I reworked the
patch. It has the same functionality as before, but this module uses
the module loader/symbol resolver for all the functions in libata, and
allows libsas to (optionally) call into sas_ata with weak references by
pushing a table of the necessary function pointers into libsas at
sas_ata load time. Thus, libsas doesn't need to load libata/sas_ata
unless it actually finds a SATA device.
The libsas code should directly call libata functions. If ATA support
in libsas is disabled in .config, then those functions will never be
called, thus never loaded the libata module.
I certainly can (and now do) call libata functions from sas_ata.
However, there are a few cases where libsas needs to call libata (ex.
sas_ioctl); for those cases, I think the function pointers are still
necessary because I don't want to make libsas require libata. In any
case, if ATA support is disabled in .config, sata_is_dev always returns
0, so the dead-code eliminator should zap that out of libsas entirely.
Looks MUCH better to me, and eliminates my objection to the
libata-related hooks.
There remains the issue that I poke James about on IRC, namely that
there is no need to emulate the SATA phy registers. libata permits a
driver high level access to the ATA engine without needing SATA SCRs.
Witness all the PATA drivers, which obviously do not have SCRs at all.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
