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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 1 Oct 2009 13:08:50 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Andi Kleen <ak@...ux.intel.com>
Cc:	"H. Peter Anvin" <hpa@...or.com>,
	Hidetoshi Seto <seto.hidetoshi@...fujitsu.com>,
	Huang Ying <ying.huang@...el.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/5] x86, mce: rename finished to valid in struct mce II


* Andi Kleen <ak@...ux.intel.com> wrote:

> H. Peter Anvin wrote:
>> On 09/29/2009 04:04 PM, Andi Kleen wrote:
>>> Hidetoshi Seto wrote:
>>>> Andi Kleen wrote:
>>>>> struct mce is exported to user space. I don't think it's a good idea
>>>>> to rename fields in exported structures like this.  That just causes confusion.
>>>> I don't know any other real user of this struct than the mcelog and the
>>>> mce test suite.  In other words, I expected that you (Huang and Andi) are
>>>> only users who may be confused by this kind of change.
>>> Also I should add there are other consumers of /dev/mcelog, not just
>>> mcelog/mce-inject.
>>>
>>
>> Details?
>
> e.g. mced

Am i the only one who finds Andi's reply and discussion methods in such 
matters utterly unproductive and intentionally obstructive?

Firstly, the initial sentence of:

  " Also I should add there are other consumers of /dev/mcelog, not just
    mcelog/mce-inject. "

Was IMO designed to be as unhelpful as possible, while still making his 
point. It would have been _so_ easy for Andi to be a bit more helpful to 
add this little bit of information to the sentence:

   "..., such as 'mced'."

A communication style like that sucks on lkml, a lot. It's vasteful 
(costs time) and is deceptive as well and holds up the technical 
discussion.

The "which are those?" basic question was to be expected, especially 
given that mced is a very, very obscure project barely findable via 
googling around. It's not packaged up and not available in rpmfind.net's 
vast package repo. So Andi cannot credibly claim a "oh, I thought that's 
obvious" defense.

Nor is the second (again maximally minimal) reply from Andi helpful:

   "e.g. mced"

... which still implies that "there might be others". But it does not 
tell us what _Andi_ thinks about that. A fair, honest, helpful reply 
would have been to write the truth straight away, via something like:

  " Also I should add there are other consumers of /dev/mcelog, not just
    mcelog/mce-inject. There's a tiny, still-obscure project called 
    'mced' - and there might be others although i dont know of any. 
    Granted, for our purposes, mcelog/mce-inject are the main ones to 
    care about. "

And look how such an honest and helpful reply would convey the right 
kind of technical message, instead of this multiple (and avoidable) 
ping-pong trying to spoon-feed information which still conveys a 
deceptive technical message? And that's all just because Andi apparently 
disagrees with the direction of the discussion?

This lack of basic honestly and helpfulnesss is one of the reasons why i 
have to ignore most of Andi's mails btw. Such exchanges show the attempt 
of trying to treat information as a weapon - giving it out 
conservatively while taking it in liberally and hoarding it. That's very 
much against basic FOSS principles. It is also very hard for me to trust 
a person who is willing to hurt (stand in the way of) others with such 
an ease of mind.

	Ingo
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ