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: <20120314204355.GA10187@kroah.com>
Date:	Wed, 14 Mar 2012 13:43:55 -0700
From:	Greg KH <gregkh@...uxfoundation.org>
To:	Mauro Carvalho Chehab <mchehab@...hat.com>
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

On Wed, Mar 14, 2012 at 04:35:00PM -0300, Mauro Carvalho Chehab wrote:
> 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.

Why create subdirs?  If those subdirectories are not real devices,
showing a real hierarchy, then do not create them as userspace will get
very confused very quickly.

Easy rule to remember, never mix "raw" kobjects and 'struct device',
which is what you would be doing here, right?  We can handle many
hundreds of thousands of files and devices in a single directory, no
problem.

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

That's a nice dream, it usually never happens until a few kernel
releases, after people have already written tools that rely on the
existing structure :)

Feel free to cc: me on any of these patches if you want some review of
the sysfs layout and usage.

thanks,

greg k-h
--
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/