[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20100201.044813.27473014.davem@davemloft.net>
Date: Mon, 01 Feb 2010 04:48:13 -0800 (PST)
From: David Miller <davem@...emloft.net>
To: alan@...rguk.ukuu.org.uk
Cc: jeff@...zik.org, bzolnier@...il.com, linux-ide@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 00/68] ide2libata
From: Alan Cox <alan@...rguk.ukuu.org.uk>
Date: Mon, 1 Feb 2010 11:48:24 +0000
> On Mon, 01 Feb 2010 03:17:25 -0800 (PST)
> David Miller <davem@...emloft.net> wrote:
>
>> From: Alan Cox <alan@...rguk.ukuu.org.uk>
>> Date: Mon, 1 Feb 2010 11:07:23 +0000
>>
>> > I'm amazed that you'd suggest trashing the current ATA stack to make the
>> > maintenance of the old ones easier - which aren't supposed to be in flux
>> > in the first place.
>>
>> I'm not, I'm saying leave the ATA stack as it is, but make the IDE
>> legacy layer such that PATA drivers can compile into it.
>
> I don't see the use of that either. The work has sone use in figuring out
> what the technical differences are between the old and new, and to review
> differences to see why the exist and if they matter.
And if you find the differences and that they matter, what are
you going to do, only fix things in one direction?
That won't make any sense.
And if the goal is to sort things out and keep things in sync,
what better way than to keep then physically in sync?
> 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?
--
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/
Powered by blists - more mailing lists