linux-kernel - Re: [PATCH V3] x86, UV: BAU performance and error recovery

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: <20100529000526.GA30938@suse.de>
Date:	Fri, 28 May 2010 17:05:26 -0700
From:	Greg KH <gregkh@...e.de>
To:	Cliff Wickman <cpw@....com>
Cc:	"H. Peter Anvin" <hpa@...or.com>, linux-kernel@...r.kernel.org,
	mingo@...e.hu
Subject: Re: [PATCH V3] x86, UV: BAU performance and error recovery

On Fri, May 28, 2010 at 06:36:23PM -0500, Cliff Wickman wrote:
> /proc/sgi_uv/bau_tunables would be a read/write file to display and change
> nine threshold and delay values for tuning the BAU driver.
> 
> I like debugfs, except that a distro may not build the kernel with it
> configured on.  The tunables should be available as administrative
> options on a customer kernel, not just as a development tool.

All distros have debugfs turned on now, and mounted, due to the perf
interface there, as well as a lot of other good debug information that
is present.

So you don't have to worry about that.

> And in our case the distros are already building with other such writable
> options in /proc/sgi_uv.  We'd like to postpone a wholesale move of such
> options (assuming there will be some better place) and stay with the existing
> location for this release.

So because some distro took a non-upstream patch, you want upstream to
accept the patch despite it being the incorrect place to put such a
file?  Heh, you might want to rethink that...

> I know we (the community) would like to move non-process info out of /proc.

Yes.  We also don't want new files added there that are not dealing with
processes.

> It seems to me that we need a similar filesystem for large and/or 
> administrative files.  That's my perspective.

I do not know of any other such "large administrative" file that needs
to be added to the system at such a time, becides this one, do you?

So please, just put it in debugfs.

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/