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: <20100528222321.GC25513@suse.de>
Date:	Fri, 28 May 2010 15:23:21 -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 02:43:35PM -0500, Cliff Wickman wrote:
> 
> On Fri, May 28, 2010 at 09:47:25AM -0700, Greg KH wrote:
> > On Fri, May 28, 2010 at 09:30:25AM -0700, H. Peter Anvin wrote:
> > > On 05/28/2010 06:33 AM, Cliff Wickman wrote:
> > > > - adds modification of tuning variables through /proc/sgi_uv
> > > 
> > > Adding new directories in /proc for a proprietary architecture is
> > > frowned upon, to put it mildly.  At the very least try to find a place
> > > in sysfs for it.
> > > 
> > > [Cc: gregkh in order to find a place in sysfs]
> > 
> > Hm, what type of files are you needing here?  Do they corrispond with
> > any specific hardware devices?  If so, just put them on the hardware
> > devices in sysfs.
> > 
> > thanks,
> > 
> > greg k-h
> 
> There is an SGI-specific directory in sysfs: /sys/firmware/sgi_uv
> though the tuning variables for the handling of the hardware Broadcast
> Assist Unit don't fit there very logically.  
> 
> The BAU's statistics are already displayed through the UV-only
> /proc/sgi_uv/ptc_statistics.  This was deemed necessary because of the
> potentially very large size of that file --- it is still true that a /sys file
> is limited to one page, is it not?

It is limited to one single value, which would never be larger than a
page, so yes, it is limited to one page.

What kind of information are you showing here?  Should this thing just
be in debugfs instead?  You can do whatever you want there.

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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ