On Fri, May 28, 2010 at 03:23:21PM -0700, Greg KH wrote:Would the similar filesystem you propose be backed by permanent storage, unlike /proc?
On Fri, May 28, 2010 at 02:43:35PM -0500, Cliff Wickman wrote:/proc/sgi_uv/bau_tunables would be a read/write file to display and change
On Fri, May 28, 2010 at 09:47:25AM -0700, Greg KH wrote:It is limited to one single value, which would never be larger than a
On Fri, May 28, 2010 at 09:30:25AM -0700, H. Peter Anvin wrote:There is an SGI-specific directory in sysfs: /sys/firmware/sgi_uv
On 05/28/2010 06:33 AM, Cliff Wickman wrote:Hm, what type of files are you needing here? Do they corrispond with
- adds modification of tuning variables through /proc/sgi_uvAdding 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]
any specific hardware devices? If so, just put them on the hardware
devices in sysfs.
thanks,
greg k-h
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?
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
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.
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.
I know we (the community) would like to move non-process info out of /proc.
It seems to me that we need a similar filesystem for large and/or
administrative files. That's my perspective.
-Cliff