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]

Message-ID: <20100201125845.3f468363@lxorguk.ukuu.org.uk>
Date:	Mon, 1 Feb 2010 12:58:45 +0000
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	David Miller <davem@...emloft.net>
Cc:	jeff@...zik.org, bzolnier@...il.com, linux-ide@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 00/68] ide2libata

> > The old drivers contain a fair amount of crap, magic and gueswork so a
> > good deal of human analysis and testing is needed to move any change
> > around and prove it's real and valid not guesswork and fudging.
> 
> And then once that hard work is done, we kind of just toss it
> for one side of the equation?

I don't where you got that idea from.

The "merge" makes it harder to maintain both, adds lots of ifdefs and
artificial divisions of code stuffed into include files. Its ugly as sin
and makes *both* sets of drivers harder to maintain.

So it's quite clearly cheaper and more efficient to propogate any
relevant fixes both directions than produce a single ifdef and include
filled turdpile that can't be maintained at all. It's not as if either
set of drivers change on a regular basis.

Plus I'd point out the calling patterns, locking and the assumptions of
the two stacks are not quite the same. There are also things the old
stack can't do (eg hotplug, queued commands, intelligent serializing
of command sequences) or that the current stack can't do (generally
because they make no sense moving forward but also stuff like user
issued SETXFER snooping)

Alan
--
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/