linux-kernel - Re: [PATCH 4/5] pata: Update experimental tags

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: <200911191645.29885.bzolnier@gmail.com>
Date:	Thu, 19 Nov 2009 16:45:29 +0100
From:	Bartlomiej Zolnierkiewicz <bzolnier@...il.com>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Alan Cox <alan@...ux.intel.com>, linux-kernel@...r.kernel.org,
	linux-ide@...r.kernel.org
Subject: Re: [PATCH 4/5] pata: Update experimental tags

On Thursday 19 November 2009 16:22:45 Alan Cox wrote:
> > If you know about other drivers still using ->pre_reset for cable detection
> > please let us know because they need fixing ASAP.
> > 
> > ->cable_detect method is there for a reason,
> 
> Given that I added it I may know more about it than you do. In fact from
> the rubbish you spout below it seems I do.

lol, I always heard that debugging other people's code is harder than
writing it in the first place..

> > already have a buggy cable detection (since ->pre_reset ignores the mandatory
> 
> Wrong.

You cannot know it unless you know how chip operates internally.  That's it.

You are taking chances that the controller does what most of similar hardware
do.  Unfortunately we have seen so many counterexamples of this in the past
(i.e. I wouldn't be so surprised if some hosts just snoop IDENTIFY data to get
their cable info) that I prefer to stick to safe approaches.

Especially since it cost us nothing and provides additional benefit of having
coherent API.

> > by spec part of cable detection which is probing slave before master) and
> 
> Have a free hint. If the host detects the cable type then we don't ask
> the drive. See the standard if you don't understand why. Even if we
> didn't the code would still be correct because we properly evaluate
> the speed configuration from all the data sources.

Please spare your 'free hints' and preaching tone.   You've completely failed
over four years span to out do the messy code even with like ~1.5 year handicap
to finalize the hostile takeover.

I'm completely fed up with the process and I'm simply fixing up your mess now,
50+ patches and counting.  Turns out to be order of magnitude more productive
than even trying to discuss things with you and/or your influential friends.

-- 
Bartlomiej Zolnierkiewicz
--
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/