linux-kernel - Re: [PATCH 00/68] ide2libata

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 29 Jan 2010 16:40:47 -0500
From:	Jeff Garzik <jeff@...zik.org>
To:	Bartlomiej Zolnierkiewicz <bzolnier@...il.com>
CC:	linux-ide@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 00/68] ide2libata

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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/