From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 21 11:02:06 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id E6AB4106566C; Mon, 21 Nov 2011 11:02:06 +0000 (UTC) Date: Mon, 21 Nov 2011 11:02:06 +0000 From: Alexander Best To: Benjamin Kaduk Message-ID: <20111121110206.GA63744@freebsd.org> References: <20111117002438.GA55931@freebsd.org> <201111172055.pAHKtZso061118@triton8.kn-bremen.de> <20111118203122.GA9508@freebsd.org> <20111120124034.GA54811@freebsd.org> <20111120140450.GA62286@freebsd.org> <20111120142131.GA64913@freebsd.org> <4eca40f5.fvA0Xb1G9w+wuGj6%perryh@pluto.rain.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: freebsd-hackers@freebsd.org, perryh@pluto.rain.com, nox@jelal.kn-bremen.de Subject: Re: easy way to determine if a stream or fd is seekable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2011 11:02:07 -0000 On Mon Nov 21 11, Benjamin Kaduk wrote: > On Mon, 21 Nov 2011, perryh@pluto.rain.com wrote: > > >Alexander Best wrote: > > > >>here's a revised patch. > >>... > >>+.Sh CAVEATS > >>+If the > >>+.Fn lseek > >>+system call is operating on a device, which is incapable of seeking, > >>+it will request the seek operation and complete successfully. > > > >I think it would be better without the first comma (after "device"). > > Definitely. > > Also, > > +.Sh CAVEATS > +If the > +.Fn lseek > +system call is operating on a device, which is incapable of seeking, > +it will request the seek operation and complete successfully. > > I would prefer something like "request the seek operation and return as if > the seek was successful, even though no seek was performed." > > +The value of the pointer associated with such a device is undefined. > > "Which pointer?" That it is "the file offset" was clear from context > where this line was moved from, but is no longer, here. > > +Device types which can be incapable of seeking include, > +but are not limited to, tape drives. > > This is an awkward phrasing; perhaps just "Many tape drives are incapable > of seeking and can trigger this bug."? this is too limited. this suggests that only certain tape drives won't seek after a successfull return of lseek(). as i mentioned beforehand, this is also the case with device with insertable media, such as dvd and blue-ray drives. here lseek() will sucessfully return, without a media inserted. i'll rephrase the whole patch and will submit a revised version. i think a reference to POLA, would also be a good idea, as suggested by perry@ thanks for all the suggestions. cheers. alex > > -Ben Kaduk