linux-kernel - Re: [PATCH 0/6] Add a per-dimm structure

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: <4F60F2E4.7060707@redhat.com>
Date:	Wed, 14 Mar 2012 16:35:00 -0300
From:	Mauro Carvalho Chehab <mchehab@...hat.com>
To:	Greg KH <gregkh@...uxfoundation.org>
CC:	Linux Edac Mailing List <linux-edac@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/6] Add a per-dimm structure

Em 13-03-2012 20:32, Greg KH escreveu:
> On Wed, Mar 07, 2012 at 08:40:32AM -0300, Mauro Carvalho Chehab wrote:
>> Prepare the internal structures to represent the memory properties per dimm, 
>> instead of per csrow. 
>>
>> This is needed for modern controllers with more than 2 channels, as the memories 
>> at the same slot number but on different channels (or channel pairs) may be 
>> different.
>>
>> Mauro Carvalho Chehab (6):
>>   edac: Create a dimm struct and move the labels into it
>>   edac: Add per dimm's sysfs nodes
> 
> You need Documentation/ABI entries for these new sysfs files.

Sure. I'll provide it on the final patchset.

Boris suggested some alternatives for the error counter sysfs nodes, but the 
discussion ended by diverging into an implementation detail of hiding the UE
error nodes, without any consensus about the sysfs structure for it.

At the current patchset, the error counter nodes are all under
	sys/devices/system/edac/mc/mc?/

He thinks that a multi-layer struct should be created inside that directory
(it could have 2 or 3 levels of directories, depending on how the memory is
organized at the memory controller), instead of having a large number of files
there.

Anyway, before adding unnedded complexity, I'd like to hear more comments from 
the others before writing a complex patch to create such structure.

So, maybe I could just add what it was there as ABI/testing, and give more
time for kernel and userspace developers to work with it and provide us a better
feedback.

Thanks,
Mauro
--
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/