linux-kernel - Re: [PATCH 2/7] staging: unisys: move uislib/platform proc entry to debugfs

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] [day] [month] [year] [list]

Message-ID: <C97001BC43954D438ACB059713BA5CDFA47DDAD940@USEA-EXCH7.na.uis.unisys.com>
Date:	Tue, 20 May 2014 08:20:49 -0500
From:	"Romer, Benjamin M" <Benjamin.Romer@...sys.com>
To:	Greg KH <gregkh@...uxfoundation.org>
CC:	*S-Par-Maintainer <SParMaintainer@...sys.com>,
	Dan Carpenter <dan.carpenter@...cle.com>,
	"devel@...verdev.osuosl.org" <devel@...verdev.osuosl.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/7] staging: unisys: move uislib/platform proc entry to
 debugfs

On Tue, 2014-05-20 at 10:09 +0900, Greg KH wrote:
> On Mon, May 19, 2014 at 10:57:08PM +0300, Dan Carpenter wrote:
> > On Mon, May 19, 2014 at 09:42:22AM -0500, Romer, Benjamin M wrote:
> > > On Sun, 2014-05-18 at 09:49 -0700, Greg KH wrote:
> > > > Also, why are these entries moving to debugfs at all?  Why are they
> > > > needed?  Who will use them?  Are tools relying on them to be there?
> > > 
> > > The tuning entries are sometimes used to help adjust the behavior of our
> > > IO service partitions for better performance.
> > 
> > That sounds like it really belongs in sysfs instead of debugfs.
> 
> Exactly.  debugfs files are for "debugging".  Consider them files that
> your driver can work properly if no one ever touches them.
> 

That is what I was trying to say - these are used when someone is
changing the behavior of IO service partitions, not the guest partition
where the driver is running. No typical user will need or want to change
these settings - only someone working on the IO *server side*
performance will need access to them. All of our drivers communicate
with another partition to perform IO on shared devices. By turning off
features, or changing the rate of messaging in the channels, it makes it
easier for someone working on the IO service partition to tune the
performance there. The guest itself isn't being tuned.

> "tuning" files imply something that has to be touched by users.
> Ideally, you would never need such a thing as no one wants to have to
> write things to files to make the kernel work better.  

That is indeed what we want - a user should not need to touch these
settings. Someone manipulating these particular settings would be
tweaking performance on the server end, like I was trying to say. I
believe that most of our proc entries are really debug-time tweaks of
that sort, and not something a typical user would ever want to touch.

> But if you really
> need it, they should be sysfs files, with the needed documentation.
> 
> thanks,
> 
> greg k-h

Sorry about the confusion! 

-- 
Ben Romer | Software Engineer |
Virtual Systems Development 

Unisys Corporation |  2476
Swedesford Rd |  Malvern, PA 19355
|  610-648-7140