On 01/29/2010 11:03 AM, Bartlomiej Zolnierkiewicz wrote:
Hi,
Here is a patchset (on top of atang-v3.1 tree) applying "out-of-the-box"
thinking to duplicated libata PATA and IDE subsystem host driver sets.
Namely, it modifies IDE API slightly to match libata's one more, adds
a tiny source-code level translation layer (ide2libata.h header file
which consists of only 17 lines of code) and then converts host drivers
to use shared source code for low-level operations (all drivers have
been carefully audited during porting to minimize the probability of
adding regressions accidentally). As an end result it is much easier
to maintain both driver sets (differences between 'new'/'old' drivers
are now apparent and there is no longer a need to manually back-port
many classes of bugfixes) and over 2500 LOC are gone.
Interesting.
I'm fine with applying patches 2-5, but I am definitely interested to
hear what others think about this. Clearly, LOC is reduced, but that's
not the only factor in code maintenance.
With regards to libata and old-IDE, I have always thought the ideal
scenario was to leave old-IDE in bugfix-only mode, with next-to-no API
or driver churn besides that which is absolutely required for the fix.
En masse backporting bug fixes is what's known as a one-time cost. Once
the majority of libata PATA drivers reach bugfix and feature parity, the
need for code sharing is reduced greatly.
The ide2libata proposal creates on-going costs, not just a one-time
cost, because the old-IDE drivers will have -increased- potential for
problems when a libata PATA driver is modified. Such is the -cost- of
heavily intertwined code sharing. A single header change implies that
two, not one, drivers might break. That weakens the "leave it alone"
stability promise of old-IDE.
Waiting for other comments... this patchset is not an onerous burden to
libata, but I think it creates nasty cross-tree issues, potentially
perturbing old-IDE.
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
