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: <4FABD9F0.6050008@redhat.com>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ