From owner-freebsd-arch@FreeBSD.ORG Sun Nov 13 11:29:31 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7D256106566C for ; Sun, 13 Nov 2011 11:29:31 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id E45858FC08 for ; Sun, 13 Nov 2011 11:29:30 +0000 (UTC) Received: from alf.home (alf.kiev.zoral.com.ua [10.1.1.177]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id pADBDdfx030352 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 13 Nov 2011 13:13:39 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from alf.home (kostik@localhost [127.0.0.1]) by alf.home (8.14.5/8.14.5) with ESMTP id pADBDdrv093851; Sun, 13 Nov 2011 13:13:39 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by alf.home (8.14.5/8.14.5/Submit) id pADBDcef093850; Sun, 13 Nov 2011 13:13:38 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: alf.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 13 Nov 2011 13:13:38 +0200 From: Kostik Belousov To: Poul-Henning Kamp Message-ID: <20111113111338.GX50300@deviant.kiev.zoral.com.ua> References: <4ebf4e1f.hkNuKvwPEzh2GJhi%perryh@pluto.rain.com> <15483.1321181667@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xts/o66bJCDUp3W0" Content-Disposition: inline In-Reply-To: <15483.1321181667@critter.freebsd.dk> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: tim@kientzle.com, perryh@pluto.rain.com, freebsd-arch@freebsd.org Subject: Re: [PATCH] fadvise(2) system call X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2011 11:29:31 -0000 --xts/o66bJCDUp3W0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Nov 13, 2011 at 10:54:27AM +0000, Poul-Henning Kamp wrote: > In message <4ebf4e1f.hkNuKvwPEzh2GJhi%perryh@pluto.rain.com>, perryh@plut= o.rain > .com writes: > >Warner Losh wrote: >=20 > >> >> wrote: > >> >>> ... seek(2) is badly broken on tape drives. > >> >>> It does nothing and doesn't return an error ... > >> >>=20 > >> >> Honestly, I think we've got bigger problems to worry about > >> >> than whether lseek() works on magnetic tape drives ... > >> >=20 > >> > True, but failing silently -- doing nothing but not returning an > >> > error -- is a POLA violation. Those are worth fixing simply on > >> > principle. > >> > >> Early Unix layering made that kinda hard... :( > > > >and yet, it somehow manages to return an error if applied to a pipe. > >There must be some point at which the inode type affects the result. >=20 > There is a big difference: pipes operate at the fdesc level, devices > sit behind what can best be explained as a symlink into a different > name-space, and the cdevsw API does not pass the fdesc offset in. I do not think this is true. Devfs does pass the file offset as uio_offset to the cdevsw read and write methods. Also, the dev nodes are marked as seekable. Drivers can see the file offset and operate on them properly, but not at the lseek(2) time. --xts/o66bJCDUp3W0 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk6/pmIACgkQC3+MBN1Mb4jkdQCgjeSrEBr7Nche80zypS8vpQTl 6lMAn19exjL9N8n2YYDmxQtWgDwG1XuG =GPhu -----END PGP SIGNATURE----- --xts/o66bJCDUp3W0--