linux-kernel - Re: [EDAC ABI v13 04/25] events/hw_event: Create a Hardware Events Report Mecanism (HERM)

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:	Thu, 10 May 2012 12:08:32 -0300
From:	Mauro Carvalho Chehab <mchehab@...hat.com>
To:	Borislav Petkov <bp@...64.org>
CC:	Linux Edac Mailing List <linux-edac@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Doug Thompson <norsk5@...oo.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Ingo Molnar <mingo@...hat.com>,
	Tony Luck <tony.luck@...el.com>,
	gregkh <gregkh@...uxfoundation.org>
Subject: Re: [EDAC ABI v13 04/25] events/hw_event: Create a Hardware Events
 Report Mecanism (HERM)

Em 10-05-2012 11:53, Mauro Carvalho Chehab escreveu:
> Em 10-05-2012 10:41, Borislav Petkov escreveu:
>> On Thu, May 10, 2012 at 10:16:31AM -0300, Mauro Carvalho Chehab wrote:
>>> Nah, this is not marketing speak. HERM is not a trademark. amd64_edac,
>>> on the other hand, is using a trademark on his name. If we use your
>>> logic, this would need to be renamed to something else, to avoid using
>>> a "marketing speak".
>>
>> I'm not even going to dignify that with an answer because it is a bunch
>> of bullshit and you know it.
>>
>>> We need some name to differentiate between the broken EDAC core where
>>> modern memory controllers are not properly represented and reports
>>> errors on fake csrows/channels from the EDAC+HERM core that will
>>> properly provide the error information to where it really belongs.
>>
>> A kernel version or a commit id is not enough here I guess.
>>
>>> In other words, HERM is just an acronym[1] to the version to point to
>>> where EDAC starts to work fine with modern memory controllers.
>>
>> Seems to me you're desperately trying to prove your point for having
>> this HERM thing by coming up with a bunch of bogus arguments.
>>
>> And I'm still waiting for a real, technical reason which legitimizes
>> calling a tracepoint something special.
> 
> Technical reasons were provided already: before this patch series, EDAC
> is *broken*.

There's also another technical reason to give an acronym to the EDAC version
that actually works: changeset numbers are not consistent within distributions
(or other trees, like -stable - although this 60+ patch series probably won't
fit on -stable merging criteria).

Also, this EDAC changeset 60+ patch series can't be represented by a single
changeset, and requires userspace changes in order to get a proper
representation model for memories.

Tagging the EDAC core version with a name helps a lot when dealing with all
the unsolved bugzillas that will be closed by backporting this patch series 
in order to fix the serious EDAC core bug that were providing fake information
to the end user for all Intel memory controllers manufactured after 2005.

Regards,
Mauro

> 
> Mauro.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-edac" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

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