From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jamie Lokier Subject: Re: [PATCH 03/15] osst: Update ppos instead of using file->f_pos Date: Fri, 20 Nov 2009 17:16:56 +0000 Message-ID: <20091120171656.GI20634@shareable.org> References: <1258735245-25826-1-git-send-email-jblunck@suse.de> <1258735245-25826-4-git-send-email-jblunck@suse.de> <20091120171317.GH20634@shareable.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-fsdevel@vger.kernel.org, Christoph Hellwig , Alan Cox , Linux-Kernel Mailinglist , Andrew Morton , Thomas Gleixner , jkacur@redhat.com, Arnd Bergmann , =?iso-8859-1?Q?Fr=E9d=E9ric?= Weisbecker , Willem Riede , "James E.J. Bottomley" To: Jan Blunck Return-path: Content-Disposition: inline In-Reply-To: <20091120171317.GH20634@shareable.org> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org Jamie Lokier wrote: > Jan Blunck wrote: > > osst_read()/osst_write() modify file->f_pos directly instead of the ppos > > given to them. The VFS later updates the file->f_pos and overwrites it > > with the value of ppos. > > I notice st.c doesn't use or update file->f_pos (or *ppos), so > userspace probably won't be caring about f_pos from osst.c (they're > both SCSI tape drivers). And osst.c doesn't use the value, it just > increases it with each transfer. It doesn't even reset the value to > zero when rewinding the tape, so it's not that meaningful. > > So how about just removing those modifications to file->f_pos from osst.c? Or alternatively, perhaps they are missing from st.c. I don't know, but userspace can't have been all that dependent on the value :-) -- Jamie