Received: with ECARTIS (v1.0.0; list xfs); Sat, 11 Nov 2006 09:13:32 -0800 (PST) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kABHDOaG031710 for ; Sat, 11 Nov 2006 09:13:25 -0800 X-ASG-Debug-ID: 1163265156-20206-472-0 X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com (Spam Firewall) with ESMTP id 38A8B517FDC for ; Sat, 11 Nov 2006 09:12:37 -0800 (PST) Received: from [10.0.0.4] (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id E98E018CF23E6; Sat, 11 Nov 2006 11:12:35 -0600 (CST) Message-ID: <45560483.5000303@sandeen.net> Date: Sat, 11 Nov 2006 11:12:35 -0600 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: Christoph Hellwig CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH] remove unused filp from ioctl functions Subject: Re: [PATCH] remove unused filp from ioctl functions References: <4555437B.4040904@sandeen.net> <20061111105627.GB3356@infradead.org> In-Reply-To: <20061111105627.GB3356@infradead.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=3.5 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.02, rules version 3.0.25705 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-archive-position: 9599 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Content-Length: 400 Lines: 12 Christoph Hellwig wrote: > On Fri, Nov 10, 2006 at 09:28:59PM -0600, Eric Sandeen wrote: >> There's a stuct file * passed around the ioctl code that is never >> used... just takes up precious stack space near as I can tell :) > > While you're at it kill the inode paramater anyway, it can be retrieved > from the vnode by trivial address arithmetics. Hadn't noticed, let me look into that. -Eric