From owner-freebsd-arch@FreeBSD.ORG Mon Jul 30 18:04:37 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 969AA1065670; Mon, 30 Jul 2012 18:04:37 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 6DEEE8FC17; Mon, 30 Jul 2012 18:04:37 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id C9F98B962; Mon, 30 Jul 2012 14:04:36 -0400 (EDT) From: John Baldwin To: "George Neville-Neil" Date: Mon, 30 Jul 2012 09:31:13 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <3CE55F29-A5B2-44A7-8854-1ED38BAE6F16@FreeBSD.org> In-Reply-To: <3CE55F29-A5B2-44A7-8854-1ED38BAE6F16@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201207300931.13116.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 30 Jul 2012 14:04:36 -0400 (EDT) Cc: arch@freebsd.org Subject: Re: aio in GENERIC? 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: Mon, 30 Jul 2012 18:04:37 -0000 On Wednesday, July 18, 2012 10:43:42 am George Neville-Neil wrote: > Howdy, > > I was wondering why aio is not yet in GENERIC. Now that it's properly > locked and all. GENERIC does have it as a module so 'kldload aio' or 'aio_load=YES' in loader.conf works for folks who need it. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Mon Jul 30 19:27:36 2012 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CAC6D106566C; Mon, 30 Jul 2012 19:27:36 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id BC3A68FC17; Mon, 30 Jul 2012 19:27:35 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id WAA17702; Mon, 30 Jul 2012 22:27:34 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Svvcr-0003ie-UQ; Mon, 30 Jul 2012 22:27:34 +0300 Message-ID: <5016E023.2080108@FreeBSD.org> Date: Mon, 30 Jul 2012 22:27:31 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120728 Thunderbird/14.0 MIME-Version: 1.0 To: John Baldwin References: <3CE55F29-A5B2-44A7-8854-1ED38BAE6F16@FreeBSD.org> <201207300931.13116.jhb@freebsd.org> In-Reply-To: <201207300931.13116.jhb@freebsd.org> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: George Neville-Neil , arch@FreeBSD.org Subject: Re: aio in GENERIC? 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: Mon, 30 Jul 2012 19:27:36 -0000 on 30/07/2012 16:31 John Baldwin said the following: > On Wednesday, July 18, 2012 10:43:42 am George Neville-Neil wrote: >> Howdy, >> >> I was wondering why aio is not yet in GENERIC. Now that it's properly >> locked and all. > > GENERIC does have it as a module so 'kldload aio' or 'aio_load=YES' in > loader.conf works for folks who need it. > The same could be said about many other drivers that are in GENERIC _kernel_. So, what was your point? :-) -- Andriy Gapon From owner-freebsd-arch@FreeBSD.ORG Mon Jul 30 20:08:12 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D138B1065673; Mon, 30 Jul 2012 20:08:12 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id A6F948FC0C; Mon, 30 Jul 2012 20:08:12 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 0478EB9A6; Mon, 30 Jul 2012 16:08:12 -0400 (EDT) From: John Baldwin To: Andriy Gapon Date: Mon, 30 Jul 2012 15:58:01 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <3CE55F29-A5B2-44A7-8854-1ED38BAE6F16@FreeBSD.org> <201207300931.13116.jhb@freebsd.org> <5016E023.2080108@FreeBSD.org> In-Reply-To: <5016E023.2080108@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201207301558.01623.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 30 Jul 2012 16:08:12 -0400 (EDT) Cc: George Neville-Neil , arch@freebsd.org Subject: Re: aio in GENERIC? 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: Mon, 30 Jul 2012 20:08:12 -0000 On Monday, July 30, 2012 3:27:31 pm Andriy Gapon wrote: > on 30/07/2012 16:31 John Baldwin said the following: > > On Wednesday, July 18, 2012 10:43:42 am George Neville-Neil wrote: > >> Howdy, > >> > >> I was wondering why aio is not yet in GENERIC. Now that it's properly > >> locked and all. > > > > GENERIC does have it as a module so 'kldload aio' or 'aio_load=YES' in > > loader.conf works for folks who need it. > > > > The same could be said about many other drivers that are in GENERIC _kernel_. > So, what was your point? :-) I don't think aio was out of GENERIC because it wasn't locked IIRC, just that it had few users. Is there any popular software that uses it? -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Mon Jul 30 20:17:54 2012 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5663F106564A; Mon, 30 Jul 2012 20:17:54 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 40A7E8FC0A; Mon, 30 Jul 2012 20:17:53 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id XAA18047; Mon, 30 Jul 2012 23:17:52 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1SvwPX-0003m0-P1; Mon, 30 Jul 2012 23:17:51 +0300 Message-ID: <5016EBEE.5020701@FreeBSD.org> Date: Mon, 30 Jul 2012 23:17:50 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120728 Thunderbird/14.0 MIME-Version: 1.0 To: John Baldwin References: <3CE55F29-A5B2-44A7-8854-1ED38BAE6F16@FreeBSD.org> <201207300931.13116.jhb@freebsd.org> <5016E023.2080108@FreeBSD.org> <201207301558.01623.jhb@freebsd.org> In-Reply-To: <201207301558.01623.jhb@freebsd.org> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: George Neville-Neil , arch@FreeBSD.org Subject: Re: aio in GENERIC? 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: Mon, 30 Jul 2012 20:17:54 -0000 on 30/07/2012 22:58 John Baldwin said the following: > On Monday, July 30, 2012 3:27:31 pm Andriy Gapon wrote: >> on 30/07/2012 16:31 John Baldwin said the following: >>> On Wednesday, July 18, 2012 10:43:42 am George Neville-Neil wrote: >>>> Howdy, >>>> >>>> I was wondering why aio is not yet in GENERIC. Now that it's properly >>>> locked and all. >>> >>> GENERIC does have it as a module so 'kldload aio' or 'aio_load=YES' in >>> loader.conf works for folks who need it. >>> >> >> The same could be said about many other drivers that are in GENERIC _kernel_. >> So, what was your point? :-) > > I don't think aio was out of GENERIC because it wasn't locked IIRC, just that > it had few users. Is there any popular software that uses it? > Honestly - I don't know. But it's in POSIX ("REALTIME"); qemu and firefox used to depend on it (to require it, actually), not sure how about now. Besides, if it's George who is going to be the user then the argument is moot :-) -- Andriy Gapon From owner-freebsd-arch@FreeBSD.ORG Tue Jul 31 20:59:38 2012 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 99EEA106566B for ; Tue, 31 Jul 2012 20:59:38 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 62FA18FC08; Tue, 31 Jul 2012 20:59:38 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q6VKxcHf082267; Tue, 31 Jul 2012 20:59:38 GMT (envelope-from bapt@FreeBSD.org) Received: (from bapt@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q6VKxbCA082266; Tue, 31 Jul 2012 20:59:37 GMT (envelope-from bapt@FreeBSD.org) X-Authentication-Warning: freefall.freebsd.org: bapt set sender to bapt@FreeBSD.org using -f Date: Tue, 31 Jul 2012 20:59:35 +0000 From: Baptiste Daroussin To: Thomas Dickey Message-ID: <20120731205935.GT21678@ithaqua.etoilebsd.net> References: <20120720082300.GA5077@debian50-32.invisible-island.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="uk6W7isEeLAaRh3S" Content-Disposition: inline In-Reply-To: <20120720082300.GA5077@debian50-32.invisible-island.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD-arch Arch Subject: Re: Flex update 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: Tue, 31 Jul 2012 20:59:38 -0000 --uk6W7isEeLAaRh3S Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 20, 2012 at 04:23:00AM -0400, Thomas Dickey wrote: > On Thu, Jul 19, 2012 at 10:42:15PM -0600, Warner Losh wrote: > > Is there some reason that flex has never been updated from 2.4.5a? >=20 > It depends on what you mean by "updated". >=20 > The usual answer is the sourceforge project. > It's not exactly an "update", since it breaks existing applications, > and its maintainer is unwilling to address those problems. >=20 > Debian for instance has old/new versions. >=20 > I don't use either - see >=20 > http://invisible-island.net/reflex/ >=20 > (earlier this year, Baptiste Daroussin suggested some additional changes > to this version, along the lines of the ones I incorporated into byacc). >=20 > --=20 > Thomas E. Dickey > http://invisible-island.net > ftp://invisible-island.net reflex seems like a better solution for us than upgrade to flex (from sourceforge) imho, flex depends on m4 and on some gnu m4 extensions, normal= ly our version of m4 is now compatible with gnu m4 (I added some missing bits recently) but still I don't think having flex using m4 is a good idea, and reflex looks cleaner in that area. reflex is just missing imho one feature from flex (sourceforge version) tha= t is ability to generate reentrant code. I already imported byacc from invisible island, I was supposed to add some "fixes" to byacc (bde has spotted) and provide them to Thomas, sorry I have been slacking in that area recently. Once that is done, I have on my todo list importing reflex to replace our f= lex. I did feel any hurry in that area, as I don't think we are missing too much features, is there one you are particulary interested on? I was waiting for reflex to support reentrant code generation before importing it. regards, Bapt --uk6W7isEeLAaRh3S Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlAYRzcACgkQ8kTtMUmk6EymOACeICfDi+PKUWFZgt07bKtaLeEj L18AoKTi/faAXjILCyHtBUp1YdFoO5/q =bOlp -----END PGP SIGNATURE----- --uk6W7isEeLAaRh3S-- From owner-freebsd-arch@FreeBSD.ORG Tue Jul 31 21:27:47 2012 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 7A61E1065674 for ; Tue, 31 Jul 2012 21:27:47 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3723E8FC16 for ; Tue, 31 Jul 2012 21:27:47 +0000 (UTC) Received: by obbun3 with SMTP id un3so14391015obb.13 for ; Tue, 31 Jul 2012 14:27:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=qw+qmVLsSdqiFLsbpl8h81Tbx4ZQGx13EeoLAKfP69Q=; b=SXt7KSiOyHfaacWLeO31CsHHRKm3rGgsjZ5zvGRmzeKTnmql19S2CwKxC7VkAI7nw0 zoiRU2IUI6L6+CiyE3+3HbSsWbQRY7J+F5soT8oLxDWdIXIITYiJmdUKT9ptvzxhH4zs 6VLZRjAWATZKOaa1rb9IyyiaInJ2CP399/6jlv/D1uJtodfRvWDlYy8KpnmfFl+oatOQ 0ltgJLdy61N2eCaTX2/idv2kY3xJbcNoUOgOJ+Ft/IRMiqeSM8O2o08cliKVOzsxIAB5 iUIUuODae1b/qnW3LPTkLfKtXfe3MW5WRgBuD6vbHhzaWw5lAGYrR9NPruFTkH1HdiNB wDqw== Received: by 10.182.136.66 with SMTP id py2mr25806463obb.9.1343770061730; Tue, 31 Jul 2012 14:27:41 -0700 (PDT) Received: from [10.30.101.53] ([209.117.142.2]) by mx.google.com with ESMTPS id k8sm727874oeh.9.2012.07.31.14.27.40 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 31 Jul 2012 14:27:41 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20120731205935.GT21678@ithaqua.etoilebsd.net> Date: Tue, 31 Jul 2012 15:27:35 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <3DB8FADE-932D-4F13-9BA0-A68C26092490@bsdimp.com> References: <20120720082300.GA5077@debian50-32.invisible-island.net> <20120731205935.GT21678@ithaqua.etoilebsd.net> To: Baptiste Daroussin X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQnzvH4K/KVg4LNNiqz8+eetq3UVmku1zMDRo2Xoa00NYFnAB/QKHwkNaoT7oTHtoiAfN/AR Cc: Thomas Dickey , FreeBSD-arch Arch Subject: Re: Flex update 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: Tue, 31 Jul 2012 21:27:47 -0000 On Jul 31, 2012, at 2:59 PM, Baptiste Daroussin wrote: > On Fri, Jul 20, 2012 at 04:23:00AM -0400, Thomas Dickey wrote: >> On Thu, Jul 19, 2012 at 10:42:15PM -0600, Warner Losh wrote: >>> Is there some reason that flex has never been updated from 2.4.5a? >>=20 >> It depends on what you mean by "updated". >>=20 >> The usual answer is the sourceforge project. >> It's not exactly an "update", since it breaks existing applications, >> and its maintainer is unwilling to address those problems. >>=20 >> Debian for instance has old/new versions. >>=20 >> I don't use either - see >>=20 >> http://invisible-island.net/reflex/ >>=20 >> (earlier this year, Baptiste Daroussin suggested some additional = changes >> to this version, along the lines of the ones I incorporated into = byacc). >>=20 >> --=20 >> Thomas E. Dickey >> http://invisible-island.net >> ftp://invisible-island.net >=20 > reflex seems like a better solution for us than upgrade to flex (from > sourceforge) imho, flex depends on m4 and on some gnu m4 extensions, = normally > our version of m4 is now compatible with gnu m4 (I added some missing = bits > recently) but still I don't think having flex using m4 is a good idea, = and > reflex looks cleaner in that area. >=20 > reflex is just missing imho one feature from flex (sourceforge = version) that is > ability to generate reentrant code. >=20 > I already imported byacc from invisible island, I was supposed to add = some > "fixes" to byacc (bde has spotted) and provide them to Thomas, sorry I = have > been slacking in that area recently. >=20 > Once that is done, I have on my todo list importing reflex to replace = our flex. > I did feel any hurry in that area, as I don't think we are missing too = much > features, is there one you are particulary interested on? I was = waiting for > reflex to support reentrant code generation before importing it. Cool. The only new feature I need from flex is the = yypush/yypop_buffer_state. That was the reason I started down this = path, but punted when I discovered the delta was less than a dozen lines = of code. reflex I haven't had to evaluate to see if it brings that in = or not. Warner= From owner-freebsd-arch@FreeBSD.ORG Tue Jul 31 21:38:21 2012 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 C7302106566B; Tue, 31 Jul 2012 21:38:21 +0000 (UTC) (envelope-from tom@invisible-island.net) Received: from vms173005pub.verizon.net (vms173005pub.verizon.net [206.46.173.5]) by mx1.freebsd.org (Postfix) with ESMTP id 6F3E58FC0C; Tue, 31 Jul 2012 21:38:21 +0000 (UTC) Received: from par-debian50-32.jexium-island.net ([unknown] [96.255.140.153]) by vms173005.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0M81000MTO2X1NF1@vms173005.mailsrvcs.net>; Tue, 31 Jul 2012 16:37:50 -0500 (CDT) Received: from par-debian50-32.jexium-island.net (localhost [127.0.0.1]) by par-debian50-32.jexium-island.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q6VLbjmI004320 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 31 Jul 2012 17:37:45 -0400 Received: (from tom@localhost) by par-debian50-32.jexium-island.net (8.14.3/8.14.3/Submit) id q6VLbjqw004318; Tue, 31 Jul 2012 17:37:45 -0400 Date: Tue, 31 Jul 2012 17:37:45 -0400 From: Thomas Dickey To: Warner Losh Message-id: <20120731213745.GA4304@debian50-32.invisible-island.net> References: <20120720082300.GA5077@debian50-32.invisible-island.net> <20120731205935.GT21678@ithaqua.etoilebsd.net> <3DB8FADE-932D-4F13-9BA0-A68C26092490@bsdimp.com> MIME-version: 1.0 Content-type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary=17pEHd4RhPHOinZp Content-disposition: inline In-reply-to: <3DB8FADE-932D-4F13-9BA0-A68C26092490@bsdimp.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Baptiste Daroussin , Thomas Dickey , FreeBSD-arch Arch Subject: Re: Flex update X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dickey@his.com List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 21:38:22 -0000 --17pEHd4RhPHOinZp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 31, 2012 at 03:27:35PM -0600, Warner Losh wrote: >=20 > On Jul 31, 2012, at 2:59 PM, Baptiste Daroussin wrote: >=20 > > On Fri, Jul 20, 2012 at 04:23:00AM -0400, Thomas Dickey wrote: > >> On Thu, Jul 19, 2012 at 10:42:15PM -0600, Warner Losh wrote: > >>> Is there some reason that flex has never been updated from 2.4.5a? > >>=20 > >> It depends on what you mean by "updated". > >>=20 > >> The usual answer is the sourceforge project. > >> It's not exactly an "update", since it breaks existing applications, > >> and its maintainer is unwilling to address those problems. > >>=20 > >> Debian for instance has old/new versions. > >>=20 > >> I don't use either - see > >>=20 > >> http://invisible-island.net/reflex/ > >>=20 > >> (earlier this year, Baptiste Daroussin suggested some additional chang= es > >> to this version, along the lines of the ones I incorporated into byacc= ). > >>=20 > >> --=20 > >> Thomas E. Dickey > >> http://invisible-island.net > >> ftp://invisible-island.net > >=20 > > reflex seems like a better solution for us than upgrade to flex (from > > sourceforge) imho, flex depends on m4 and on some gnu m4 extensions, no= rmally > > our version of m4 is now compatible with gnu m4 (I added some missing b= its > > recently) but still I don't think having flex using m4 is a good idea, = and > > reflex looks cleaner in that area. > >=20 > > reflex is just missing imho one feature from flex (sourceforge version)= that is > > ability to generate reentrant code. yes - we seem to have agreed that if/when one of us finds time, that would be good to add. (at the moment, I was thinking of doing it, but have lynx and xterm fixes that have become more urgent...) currently I'm finishing a complicated packaging change for vile. > > I already imported byacc from invisible island, I was supposed to add s= ome > > "fixes" to byacc (bde has spotted) and provide them to Thomas, sorry I = have > > been slacking in that area recently. patches are welcome :-) > > Once that is done, I have on my todo list importing reflex to replace o= ur flex. > > I did feel any hurry in that area, as I don't think we are missing too = much > > features, is there one you are particulary interested on? I was waiting= for > > reflex to support reentrant code generation before importing it. >=20 > Cool. The only new feature I need from flex is the yypush/yypop_buffer_s= tate. That was the reason I started down this path, but punted when I disc= overed the delta was less than a dozen lines of code. reflex I haven't had= to evaluate to see if it brings that in or not. >=20 > Warner --=20 Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net --17pEHd4RhPHOinZp Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAlAYUCkACgkQcCNT4PfkjtvE4ACfbzsyIfN8BxIw4Lf0xAeghK8A Te4AoMkaNrFlVOB1Sy7zGKCLSSIaNTYr =FLRG -----END PGP SIGNATURE----- --17pEHd4RhPHOinZp-- From owner-freebsd-arch@FreeBSD.ORG Tue Jul 31 21:42:08 2012 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 94740106564A for ; Tue, 31 Jul 2012 21:42:08 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 75B8D8FC15; Tue, 31 Jul 2012 21:42:08 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q6VLg8Ks088472; Tue, 31 Jul 2012 21:42:08 GMT (envelope-from bapt@FreeBSD.org) Received: (from bapt@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q6VLg8hY088471; Tue, 31 Jul 2012 21:42:08 GMT (envelope-from bapt@FreeBSD.org) X-Authentication-Warning: freefall.freebsd.org: bapt set sender to bapt@FreeBSD.org using -f Date: Tue, 31 Jul 2012 21:42:05 +0000 From: Baptiste Daroussin To: Warner Losh Message-ID: <20120731214205.GU21678@ithaqua.etoilebsd.net> References: <20120720082300.GA5077@debian50-32.invisible-island.net> <20120731205935.GT21678@ithaqua.etoilebsd.net> <3DB8FADE-932D-4F13-9BA0-A68C26092490@bsdimp.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xmHgJexE5s//CZci" Content-Disposition: inline In-Reply-To: <3DB8FADE-932D-4F13-9BA0-A68C26092490@bsdimp.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Thomas Dickey , FreeBSD-arch Arch Subject: Re: Flex update 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: Tue, 31 Jul 2012 21:42:08 -0000 --xmHgJexE5s//CZci Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 31, 2012 at 03:27:35PM -0600, Warner Losh wrote: >=20 > On Jul 31, 2012, at 2:59 PM, Baptiste Daroussin wrote: >=20 > > On Fri, Jul 20, 2012 at 04:23:00AM -0400, Thomas Dickey wrote: > >> On Thu, Jul 19, 2012 at 10:42:15PM -0600, Warner Losh wrote: > >>> Is there some reason that flex has never been updated from 2.4.5a? > >>=20 > >> It depends on what you mean by "updated". > >>=20 > >> The usual answer is the sourceforge project. > >> It's not exactly an "update", since it breaks existing applications, > >> and its maintainer is unwilling to address those problems. > >>=20 > >> Debian for instance has old/new versions. > >>=20 > >> I don't use either - see > >>=20 > >> http://invisible-island.net/reflex/ > >>=20 > >> (earlier this year, Baptiste Daroussin suggested some additional chang= es > >> to this version, along the lines of the ones I incorporated into byacc= ). > >>=20 > >> --=20 > >> Thomas E. Dickey > >> http://invisible-island.net > >> ftp://invisible-island.net > >=20 > > reflex seems like a better solution for us than upgrade to flex (from > > sourceforge) imho, flex depends on m4 and on some gnu m4 extensions, no= rmally > > our version of m4 is now compatible with gnu m4 (I added some missing b= its > > recently) but still I don't think having flex using m4 is a good idea, = and > > reflex looks cleaner in that area. > >=20 > > reflex is just missing imho one feature from flex (sourceforge version)= that is > > ability to generate reentrant code. > >=20 > > I already imported byacc from invisible island, I was supposed to add s= ome > > "fixes" to byacc (bde has spotted) and provide them to Thomas, sorry I = have > > been slacking in that area recently. > >=20 > > Once that is done, I have on my todo list importing reflex to replace o= ur flex. > > I did feel any hurry in that area, as I don't think we are missing too = much > > features, is there one you are particulary interested on? I was waiting= for > > reflex to support reentrant code generation before importing it. >=20 > Cool. The only new feature I need from flex is the yypush/yypop_buffer_s= tate. That was the reason I started down this path, but punted when I disc= overed the delta was less than a dozen lines of code. reflex I haven't had= to evaluate to see if it brings that in or not. >=20 > Warner_______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" If you want to do the import feel free :) regards, Bapt --xmHgJexE5s//CZci Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlAYUS0ACgkQ8kTtMUmk6Eyl0ACeLpPl7fJVfZWilnjweldIqVEx /F0An0aQV0TFbMnajDh3WjcKLHboxVDN =qp+e -----END PGP SIGNATURE----- --xmHgJexE5s//CZci-- From owner-freebsd-arch@FreeBSD.ORG Wed Aug 1 02:49:16 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 21FD0106566B for ; Wed, 1 Aug 2012 02:49:16 +0000 (UTC) (envelope-from davidxu@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E97E98FC15 for ; Wed, 1 Aug 2012 02:49:15 +0000 (UTC) Received: from xyf.my.dom (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q712nE1L033454 for ; Wed, 1 Aug 2012 02:49:15 GMT (envelope-from davidxu@freebsd.org) Message-ID: <5018992C.8000207@freebsd.org> Date: Wed, 01 Aug 2012 10:49:16 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: arch@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: short read/write and error code 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: Wed, 01 Aug 2012 02:49:16 -0000 POSIX requires write() to return actually bytes written, same rule is applied to read(). http://pubs.opengroup.org/onlinepubs/009695399/functions/write.html > ETURN VALUE > > Upon successful completion, write() [XSI] and pwrite() shall > return the number of bytes actually written to the file associated > with fildes. This number shall never be greater than nbyte. > Otherwise, -1 shall be returned and errno set to indicate the error. http://pubs.opengroup.org/onlinepubs/009695399/functions/read.html > RETURN VALUE > > Upon successful completion, read() [XSI] and pread() shall return > a non-negative integer indicating the number of bytes actually read. > Otherwise, the functions shall return -1 and set errno to indicate > the error. I have following patch to fix our code to be compatible with POSIX: Index: sys_generic.c =================================================================== --- sys_generic.c (revision 238927) +++ sys_generic.c (working copy) @@ -333,8 +333,7 @@ #endif cnt = auio->uio_resid; if ((error = fo_read(fp, auio, td->td_ucred, flags, td))) { - if (auio->uio_resid != cnt && (error == ERESTART || - error == EINTR || error == EWOULDBLOCK)) + if (auio->uio_resid != cnt) error = 0; } cnt -= auio->uio_resid; @@ -539,15 +538,14 @@ if (fp->f_type == DTYPE_VNODE) bwillwrite(); if ((error = fo_write(fp, auio, td->td_ucred, flags, td))) { - if (auio->uio_resid != cnt && (error == ERESTART || - error == EINTR || error == EWOULDBLOCK)) - error = 0; /* Socket layer is responsible for issuing SIGPIPE. */ if (fp->f_type != DTYPE_SOCKET && error == EPIPE) { PROC_LOCK(td->td_proc); tdsignal(td, SIGPIPE); PROC_UNLOCK(td->td_proc); } + if (auio->uio_resid != cnt) + error = 0; } cnt -= auio->uio_resid; #ifdef KTRACE -current only resets error code to zero for short write when code is ERESTART, EINTR or EWOULDBLOCK. But this is incorrect, at least for pipe, when EPIPE is returned, some bytes may have already been written. For a named pipe, I may don't care a reader is disappeared or not, because for named pipe, a new reader can come in and talk with writer again, so I need to know how many bytes have been written, same is applied to reader, I don't care writer is gone, it can come in again and talk with reader. So I suggest to remove surplus code in -current's dofilewrite() and dofileread(). For EPIPE, We still deliver SIGPIPE to current thread, but returns actually bytes written. Regards, David Xu From owner-freebsd-arch@FreeBSD.ORG Wed Aug 1 04:19:20 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4B6C31065672; Wed, 1 Aug 2012 04:19:20 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 34C648FC0A; Wed, 1 Aug 2012 04:19:20 +0000 (UTC) Received: by elvis.mu.org (Postfix, from userid 1192) id 53F811A3CF3; Tue, 31 Jul 2012 21:11:37 -0700 (PDT) Date: Tue, 31 Jul 2012 21:11:37 -0700 From: Alfred Perlstein To: David Xu Message-ID: <20120801041137.GA56944@elvis.mu.org> References: <5018992C.8000207@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5018992C.8000207@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: arch@freebsd.org Subject: Re: short read/write and error code 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: Wed, 01 Aug 2012 04:19:20 -0000 This is cool, is there a test case that you can run on Linux/Solaris to compare expected vs actual behavior? * David Xu [120731 19:49] wrote: > POSIX requires write() to return actually bytes written, same rule is > applied to read(). > > http://pubs.opengroup.org/onlinepubs/009695399/functions/write.html > >ETURN VALUE > > > >Upon successful completion, write() [XSI] and pwrite() shall > > return the number of bytes actually written to the file associated > >with fildes. This number shall never be greater than nbyte. > > Otherwise, -1 shall be returned and errno set to indicate the error. > > > http://pubs.opengroup.org/onlinepubs/009695399/functions/read.html > >RETURN VALUE > > > >Upon successful completion, read() [XSI] and pread() shall return > > a non-negative integer indicating the number of bytes actually read. > > Otherwise, the functions shall return -1 and set errno to indicate > > the error. > > I have following patch to fix our code to be compatible with POSIX: > > Index: sys_generic.c > =================================================================== > --- sys_generic.c (revision 238927) > +++ sys_generic.c (working copy) > @@ -333,8 +333,7 @@ > #endif > cnt = auio->uio_resid; > if ((error = fo_read(fp, auio, td->td_ucred, flags, td))) { > - if (auio->uio_resid != cnt && (error == ERESTART || > - error == EINTR || error == EWOULDBLOCK)) > + if (auio->uio_resid != cnt) > error = 0; > } > cnt -= auio->uio_resid; > @@ -539,15 +538,14 @@ > if (fp->f_type == DTYPE_VNODE) > bwillwrite(); > if ((error = fo_write(fp, auio, td->td_ucred, flags, td))) { > - if (auio->uio_resid != cnt && (error == ERESTART || > - error == EINTR || error == EWOULDBLOCK)) > - error = 0; > /* Socket layer is responsible for issuing SIGPIPE. */ > if (fp->f_type != DTYPE_SOCKET && error == EPIPE) { > PROC_LOCK(td->td_proc); > tdsignal(td, SIGPIPE); > PROC_UNLOCK(td->td_proc); > } > + if (auio->uio_resid != cnt) > + error = 0; > } > cnt -= auio->uio_resid; > #ifdef KTRACE > > > -current only resets error code to zero for short write when code is > ERESTART, EINTR or EWOULDBLOCK. > But this is incorrect, at least for pipe, when EPIPE is returned, > some bytes may have already been written. For a named pipe, I may don't > care a reader is disappeared or not, because for named pipe, a new > reader can come in and talk with writer again, so I need to know > how many bytes have been written, same is applied to reader, I don't > care writer is gone, it can come in again and talk with reader. So I > suggest to remove surplus code in -current's dofilewrite() and > dofileread(). > For EPIPE, We still deliver SIGPIPE to current thread, but returns > actually bytes written. > > Regards, > David Xu > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" -- - Alfred Perlstein .- VMOA #5191, 03 vmax, 92 gs500, 85 ch250, 07 zx10 .- FreeBSD committer From owner-freebsd-arch@FreeBSD.ORG Wed Aug 1 05:09:50 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8B752106568B; Wed, 1 Aug 2012 05:09:50 +0000 (UTC) (envelope-from listlog2011@gmail.com) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 5B3208FC1B; Wed, 1 Aug 2012 05:09:50 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q7159mWs053223; Wed, 1 Aug 2012 05:09:49 GMT (envelope-from listlog2011@gmail.com) Message-ID: <5018BA1A.9070701@gmail.com> Date: Wed, 01 Aug 2012 13:09:46 +0800 From: David Xu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Alfred Perlstein References: <5018992C.8000207@freebsd.org> <20120801041137.GA56944@elvis.mu.org> In-Reply-To: <20120801041137.GA56944@elvis.mu.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org, David Xu Subject: Re: short read/write and error code X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: davidxu@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 05:09:50 -0000 On 2012/8/1 12:11, Alfred Perlstein wrote: > This is cool, is there a test case that you can run > on Linux/Solaris to compare expected vs actual > behavior? I have written a simple test program: http://people.freebsd.org/~davidxu/patch/fifopipe/fifotest.c and results are: http://people.freebsd.org/~davidxu/patch/fifopipe/typescript.linux.txt http://people.freebsd.org/~davidxu/patch/fifopipe/typescript.fbsd9.txt http://people.freebsd.org/~davidxu/patch/fifopipe/typescript.mycur.txt From owner-freebsd-arch@FreeBSD.ORG Wed Aug 1 07:19:58 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5FA44106564A; Wed, 1 Aug 2012 07:19:58 +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 D48648FC16; Wed, 1 Aug 2012 07:19:57 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q717Jlmb060448; Wed, 1 Aug 2012 10:19:47 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q717JZPD071754; Wed, 1 Aug 2012 10:19:35 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q717JZqw071753; Wed, 1 Aug 2012 10:19:35 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 1 Aug 2012 10:19:34 +0300 From: Konstantin Belousov To: David Xu Message-ID: <20120801071934.GJ2676@deviant.kiev.zoral.com.ua> References: <5018992C.8000207@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7zuzT4v7lqAOytwt" Content-Disposition: inline In-Reply-To: <5018992C.8000207@freebsd.org> 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=-4.0 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: arch@freebsd.org Subject: Re: short read/write and error code 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: Wed, 01 Aug 2012 07:19:58 -0000 --7zuzT4v7lqAOytwt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 01, 2012 at 10:49:16AM +0800, David Xu wrote: > POSIX requires write() to return actually bytes written, same rule is > applied to read(). >=20 > http://pubs.opengroup.org/onlinepubs/009695399/functions/write.html > >ETURN VALUE > > > >Upon successful completion, write() [XSI] and pwrite() shall > > return the number of bytes actually written to the file associated > >with fildes. This number shall never be greater than nbyte. > > Otherwise, -1 shall be returned and errno set to indicate the error. >=20 >=20 > http://pubs.opengroup.org/onlinepubs/009695399/functions/read.html > >RETURN VALUE > > > >Upon successful completion, read() [XSI] and pread() shall return > > a non-negative integer indicating the number of bytes actually read. > > Otherwise, the functions shall return -1 and set errno to indicate > > the error. Note that the wording is only about successful return, not for the case when error occured. I do think that if fo_read() returned an error, and error is not of the kind 'interruption', then the error shall be returned as is. >=20 > I have following patch to fix our code to be compatible with POSIX: =2E.. > -current only resets error code to zero for short write when code is > ERESTART, EINTR or EWOULDBLOCK. > But this is incorrect, at least for pipe, when EPIPE is returned, > some bytes may have already been written. For a named pipe, I may don't > care a reader is disappeared or not, because for named pipe, a new > reader can come in and talk with writer again, so I need to know > how many bytes have been written, same is applied to reader, I don't > care writer is gone, it can come in again and talk with reader. So I > suggest to remove surplus code in -current's dofilewrite() and > dofileread(). Then fix the pipe code, and not introduce the behaviour change for all file types ? > For EPIPE, We still deliver SIGPIPE to current thread, but returns > actually bytes written. And this sounds wrong. I think that fixing the code for pipes would also semi-magically makes this correct. --7zuzT4v7lqAOytwt Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlAY2IYACgkQC3+MBN1Mb4i/nACfeLJqzJODvs40AFHUWi2MFptZ Eq4An2ksw/y+tc6zSYw10+gHumPf5XP1 =bfiK -----END PGP SIGNATURE----- --7zuzT4v7lqAOytwt-- From owner-freebsd-arch@FreeBSD.ORG Wed Aug 1 07:46:54 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BF952106564A; Wed, 1 Aug 2012 07:46:54 +0000 (UTC) (envelope-from maxim.konovalov@gmail.com) Received: from mp2.macomnet.net (ipv6.irc.int.ru [IPv6:2a02:28:1:2::1b:2]) by mx1.freebsd.org (Postfix) with ESMTP id 42D198FC0A; Wed, 1 Aug 2012 07:46:54 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mp2.macomnet.net (8.14.5/8.14.5) with ESMTP id q717kqx0006398; Wed, 1 Aug 2012 11:46:52 +0400 (MSK) (envelope-from maxim.konovalov@gmail.com) Date: Wed, 1 Aug 2012 11:46:52 +0400 (MSK) From: Maxim Konovalov To: John Baldwin In-Reply-To: <201207301558.01623.jhb@freebsd.org> Message-ID: References: <3CE55F29-A5B2-44A7-8854-1ED38BAE6F16@FreeBSD.org> <201207300931.13116.jhb@freebsd.org> <5016E023.2080108@FreeBSD.org> <201207301558.01623.jhb@freebsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: George Neville-Neil , Andriy Gapon , arch@freebsd.org Subject: Re: aio in GENERIC? 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: Wed, 01 Aug 2012 07:46:54 -0000 On Mon, 30 Jul 2012, 15:58-0400, John Baldwin wrote: > On Monday, July 30, 2012 3:27:31 pm Andriy Gapon wrote: > > on 30/07/2012 16:31 John Baldwin said the following: > > > On Wednesday, July 18, 2012 10:43:42 am George Neville-Neil wrote: > > >> Howdy, > > >> > > >> I was wondering why aio is not yet in GENERIC. Now that it's properly > > >> locked and all. > > > > > > GENERIC does have it as a module so 'kldload aio' or 'aio_load=YES' in > > > loader.conf works for folks who need it. > > > > > > > The same could be said about many other drivers that are in GENERIC _kernel_. > > So, what was your point? :-) > > I don't think aio was out of GENERIC because it wasn't locked IIRC, just that > it had few users. Is there any popular software that uses it? > nginx does use it. Not by default though. -- Maxim Konovalov From owner-freebsd-arch@FreeBSD.ORG Wed Aug 1 07:59:59 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9186C106566C; Wed, 1 Aug 2012 07:59:59 +0000 (UTC) (envelope-from listlog2011@gmail.com) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 612BE8FC14; Wed, 1 Aug 2012 07:59:59 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q717xv2x083525; Wed, 1 Aug 2012 07:59:58 GMT (envelope-from listlog2011@gmail.com) Message-ID: <5018E1FC.4080609@gmail.com> Date: Wed, 01 Aug 2012 15:59:56 +0800 From: David Xu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Konstantin Belousov References: <5018992C.8000207@freebsd.org> <20120801071934.GJ2676@deviant.kiev.zoral.com.ua> In-Reply-To: <20120801071934.GJ2676@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org, David Xu Subject: Re: short read/write and error code X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: davidxu@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 07:59:59 -0000 On 2012/8/1 15:19, Konstantin Belousov wrote: > On Wed, Aug 01, 2012 at 10:49:16AM +0800, David Xu wrote: >> POSIX requires write() to return actually bytes written, same rule is >> applied to read(). >> >> http://pubs.opengroup.org/onlinepubs/009695399/functions/write.html >>> ETURN VALUE >>> >>> Upon successful completion, write() [XSI] and pwrite() shall >>> return the number of bytes actually written to the file associated >>> with fildes. This number shall never be greater than nbyte. >>> Otherwise, -1 shall be returned and errno set to indicate the error. >> >> http://pubs.opengroup.org/onlinepubs/009695399/functions/read.html >>> RETURN VALUE >>> >>> Upon successful completion, read() [XSI] and pread() shall return >>> a non-negative integer indicating the number of bytes actually read. >>> Otherwise, the functions shall return -1 and set errno to indicate >>> the error. > Note that the wording is only about successful return, not for the case > when error occured. I do think that if fo_read() returned an error, and > error is not of the kind 'interruption', then the error shall be returned > as is. I do think data is more important than error code. Do you think if a 512 bytes block is bad, all bytes in the block should be thrown away while you could really get some bytes from it, this might be very important to someone, such as a password or a bank account, this is just an example, whether filesystem works in this way is irrelevant. While program continues to execute, next read()/write() should return -1 and errno will be set, I think both socket and pipe already work in this way, it is dofileread/dofilewrite have made it not happen. >> I have following patch to fix our code to be compatible with POSIX: > ... > >> -current only resets error code to zero for short write when code is >> ERESTART, EINTR or EWOULDBLOCK. >> But this is incorrect, at least for pipe, when EPIPE is returned, >> some bytes may have already been written. For a named pipe, I may don't >> care a reader is disappeared or not, because for named pipe, a new >> reader can come in and talk with writer again, so I need to know >> how many bytes have been written, same is applied to reader, I don't >> care writer is gone, it can come in again and talk with reader. So I >> suggest to remove surplus code in -current's dofilewrite() and >> dofileread(). > Then fix the pipe code, and not introduce the behaviour change for all > file types ? see above, I think data is more important than error code, and next read/write will get the error. >> For EPIPE, We still deliver SIGPIPE to current thread, but returns >> actually bytes written. > And this sounds wrong. I think that fixing the code for pipes would also > semi-magically makes this correct. From owner-freebsd-arch@FreeBSD.ORG Wed Aug 1 09:23:17 2012 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C9160106564A; Wed, 1 Aug 2012 09:23:17 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail12.syd.optusnet.com.au (mail12.syd.optusnet.com.au [211.29.132.193]) by mx1.freebsd.org (Postfix) with ESMTP id 1879C8FC0C; Wed, 1 Aug 2012 09:23:16 +0000 (UTC) Received: from c122-106-171-246.carlnfd1.nsw.optusnet.com.au (c122-106-171-246.carlnfd1.nsw.optusnet.com.au [122.106.171.246]) by mail12.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q719NA0F026776 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Aug 2012 19:23:15 +1000 Date: Wed, 1 Aug 2012 19:23:09 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Konstantin Belousov In-Reply-To: <20120801071934.GJ2676@deviant.kiev.zoral.com.ua> Message-ID: <20120801183240.K1291@besplex.bde.org> References: <5018992C.8000207@freebsd.org> <20120801071934.GJ2676@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@FreeBSD.org, David Xu Subject: Re: short read/write and error code 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: Wed, 01 Aug 2012 09:23:17 -0000 On Wed, 1 Aug 2012, Konstantin Belousov wrote: > On Wed, Aug 01, 2012 at 10:49:16AM +0800, David Xu wrote: >> POSIX requires write() to return actually bytes written, same rule is >> applied to read(). >> >> http://pubs.opengroup.org/onlinepubs/009695399/functions/write.html >>> ETURN VALUE >>> >>> Upon successful completion, write() [XSI] and pwrite() shall >>> return the number of bytes actually written to the file associated >>> with fildes. This number shall never be greater than nbyte. >>> Otherwise, -1 shall be returned and errno set to indicate the error. >> >> http://pubs.opengroup.org/onlinepubs/009695399/functions/read.html >>> RETURN VALUE >>> >>> Upon successful completion, read() [XSI] and pread() shall return >>> a non-negative integer indicating the number of bytes actually read. >>> Otherwise, the functions shall return -1 and set errno to indicate >>> the error. > Note that the wording is only about successful return, not for the case > when error occured. I do think that if fo_read() returned an error, and > error is not of the kind 'interruption', then the error shall be returned > as is. That is clearly not what is intended. write() is unusable if it won't tell you how many bytes it wrote. According to your interpretation, recalcitrantix would conform to POSIX if all it writes wrote whatever they could and then returned -1 after detecting the error EPOSIXFUZZY. The usability is specified for signals. From an old POSIX draft: % 51235 If write( ) is interrupted by a signal before it writes any data, it shall return -1 with errno set to % 51236 [EINTR]. % 51237 If write( ) is interrupted by a signal after it successfully writes some data, it shall return the % 51238 number of bytes written. POSIX formally defines "Successfully Transferred", mainly for aio. I couldn't find any formal definition of "successfully writes", but clearly it is nonsense for a write to be unsuccessful if a reader on the local system or on an external system has successfully read some of the data written by the write. FreeBSD does try to convert EINTR to 0 after some data has been written, to conform to the above. SIGPIPE should return EINTR to be returned to dofilewrite(), so there should be no problem for SIGPIPE. But we were reminded of this old FreeBSD bug by probelms with SIGPIPE. POSIX contradicts itself by disallowing successful completion if _any_ error is detected: % 435 RETURN VALUE % 436 This section indicates the possible return values, if any. % 437 If the implementation can detect errors, ``successful completion'' means that no error % 438 has been detected during execution of the function. If the implementation does detect Relcalcitrantix has 2 versions according to which of these contradictions has precedence. In one version, writes do as much as possible before returning -1/EPOSIXFUZZY, as above. In the other version, this still happens for most writes. But ones that are interrupted by a signal after having written some data return the number of bytes written, accoding to the "shall" for the interrupted case. Perhaps there are some other weird cases where writes are required to work :-). >> I have following patch to fix our code to be compatible with POSIX: > ... > >> -current only resets error code to zero for short write when code is >> ERESTART, EINTR or EWOULDBLOCK. >> But this is incorrect, at least for pipe, when EPIPE is returned, >> some bytes may have already been written. For a named pipe, I may don't >> care a reader is disappeared or not, because for named pipe, a new >> reader can come in and talk with writer again, so I need to know >> how many bytes have been written, same is applied to reader, I don't >> care writer is gone, it can come in again and talk with reader. So I >> suggest to remove surplus code in -current's dofilewrite() and >> dofileread(). > Then fix the pipe code, and not introduce the behaviour change for all > file types ? Because returning the error to userland breaks all file types that want to return a short i/o (mainly special files whose i/o cannot be backed out of). They are just detecting and returning an error as a courtesy to upper layers, and to simplify the implementation. The syscall API doesn't permit returning both the error code (the reason for the short i/o) and the short count, so the error code must be cleared to allow the short count to be returned. Bruce From owner-freebsd-arch@FreeBSD.ORG Wed Aug 1 09:57:35 2012 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0E84B106566B; Wed, 1 Aug 2012 09:57:35 +0000 (UTC) (envelope-from listlog2011@gmail.com) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E2E148FC08; Wed, 1 Aug 2012 09:57:34 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q719vWa6016240; Wed, 1 Aug 2012 09:57:33 GMT (envelope-from listlog2011@gmail.com) Message-ID: <5018FD8B.8090309@gmail.com> Date: Wed, 01 Aug 2012 17:57:31 +0800 From: David Xu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Bruce Evans References: <5018992C.8000207@freebsd.org> <20120801071934.GJ2676@deviant.kiev.zoral.com.ua> <20120801183240.K1291@besplex.bde.org> In-Reply-To: <20120801183240.K1291@besplex.bde.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Konstantin Belousov , arch@FreeBSD.org, David Xu Subject: Re: short read/write and error code X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: davidxu@FreeBSD.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 09:57:35 -0000 On 2012/8/1 17:23, Bruce Evans wrote: > On Wed, 1 Aug 2012, Konstantin Belousov wrote: > >> On Wed, Aug 01, 2012 at 10:49:16AM +0800, David Xu wrote: >>> POSIX requires write() to return actually bytes written, same rule is >>> applied to read(). >>> >>> http://pubs.opengroup.org/onlinepubs/009695399/functions/write.html >>>> ETURN VALUE >>>> >>>> Upon successful completion, write() [XSI] and pwrite() shall >>>> return the number of bytes actually written to the file associated >>>> with fildes. This number shall never be greater than nbyte. >>>> Otherwise, -1 shall be returned and errno set to indicate the error. >>> >>> http://pubs.opengroup.org/onlinepubs/009695399/functions/read.html >>>> RETURN VALUE >>>> >>>> Upon successful completion, read() [XSI] and pread() shall return >>>> a non-negative integer indicating the number of bytes actually read. >>>> Otherwise, the functions shall return -1 and set errno to indicate >>>> the error. >> Note that the wording is only about successful return, not for the case >> when error occured. I do think that if fo_read() returned an error, and >> error is not of the kind 'interruption', then the error shall be >> returned >> as is. > > That is clearly not what is intended. write() is unusable if it won't > tell you how many bytes it wrote. According to your interpretation, > recalcitrantix would conform to POSIX if all it writes wrote whatever > they could and then returned -1 after detecting the error EPOSIXFUZZY. > > The usability is specified for signals. From an old POSIX draft: > > % 51235 If write( ) is interrupted by a signal before it > writes any data, it shall return -1 with errno set to > % 51236 [EINTR]. > % 51237 If write( ) is interrupted by a signal after it > successfully writes some data, it shall return the > % 51238 number of bytes written. > > POSIX formally defines "Successfully Transferred", mainly for aio. I > couldn't find any formal definition of "successfully writes", but clearly > it is nonsense for a write to be unsuccessful if a reader on the local > system or on an external system has successfully read some of the data > written by the write. > > FreeBSD does try to convert EINTR to 0 after some data has been written, > to conform to the above. SIGPIPE should return EINTR to be returned to > dofilewrite(), so there should be no problem for SIGPIPE. But we were > reminded of this old FreeBSD bug by probelms with SIGPIPE. > > POSIX contradicts itself by disallowing successful completion if _any_ > error is detected: > > % 435 RETURN VALUE > % 436 This section indicates the possible > return values, if any. > % 437 If the implementation can detect errors, > ``successful completion'' means that no error > % 438 has been detected during execution of the > function. If the implementation does detect > > Relcalcitrantix has 2 versions according to which of these contradictions > has precedence. In one version, writes do as much as possible before > returning -1/EPOSIXFUZZY, as above. In the other version, this still > happens for most writes. But ones that are interrupted by a signal after > having written some data return the number of bytes written, accoding to > the "shall" for the interrupted case. Perhaps there are some other weird > cases where writes are required to work :-). > Thanks, I even don't know there is such a chapter in POSIX document. >>> I have following patch to fix our code to be compatible with POSIX: >> ... >> >>> -current only resets error code to zero for short write when code is >>> ERESTART, EINTR or EWOULDBLOCK. >>> But this is incorrect, at least for pipe, when EPIPE is returned, >>> some bytes may have already been written. For a named pipe, I may don't >>> care a reader is disappeared or not, because for named pipe, a new >>> reader can come in and talk with writer again, so I need to know >>> how many bytes have been written, same is applied to reader, I don't >>> care writer is gone, it can come in again and talk with reader. So I >>> suggest to remove surplus code in -current's dofilewrite() and >>> dofileread(). >> Then fix the pipe code, and not introduce the behaviour change for all >> file types ? > > Because returning the error to userland breaks all file types that > want to return a short i/o (mainly special files whose i/o cannot be > backed out of). They are just detecting and returning an error as a > courtesy to upper layers, and to simplify the implementation. The > syscall API doesn't permit returning both the error code (the reason > for the short i/o) and the short count, so the error code must be > cleared to allow the short count to be returned. > > Bruce > The dofileread and dofilewrite are rather annoying. dofileread discards data already in hand. dofilewrite does not tell you it has written some data to media, this might have already caused some side effect. :-( From owner-freebsd-arch@FreeBSD.ORG Wed Aug 1 14:10:07 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 59850106566B for ; Wed, 1 Aug 2012 14:10:07 +0000 (UTC) (envelope-from freebsd-arch@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id 1035A8FC17 for ; Wed, 1 Aug 2012 14:10:06 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1SwZcj-0003xC-LT for freebsd-arch@freebsd.org; Wed, 01 Aug 2012 16:10:05 +0200 Received: from 208.85.208.53 ([208.85.208.53]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 01 Aug 2012 16:10:05 +0200 Received: from atkin901 by 208.85.208.53 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 01 Aug 2012 16:10:05 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-arch@freebsd.org From: Mark Atkinson Date: Wed, 01 Aug 2012 06:59:17 -0700 Lines: 40 Message-ID: References: <3CE55F29-A5B2-44A7-8854-1ED38BAE6F16@FreeBSD.org> <201207300931.13116.jhb@freebsd.org> <5016E023.2080108@FreeBSD.org> <201207301558.01623.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 208.85.208.53 User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:14.0) Gecko/20120727 Thunderbird/14.0 In-Reply-To: X-Enigmail-Version: 1.4.2 Subject: Re: aio in GENERIC? 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: Wed, 01 Aug 2012 14:10:07 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/01/2012 00:46, Maxim Konovalov wrote: > On Mon, 30 Jul 2012, 15:58-0400, John Baldwin wrote: > >> On Monday, July 30, 2012 3:27:31 pm Andriy Gapon wrote: >>> on 30/07/2012 16:31 John Baldwin said the following: >>>> On Wednesday, July 18, 2012 10:43:42 am George Neville-Neil >>>> wrote: >>>>> Howdy, >>>>> >>>>> I was wondering why aio is not yet in GENERIC. Now that >>>>> it's properly locked and all. >>>> >>>> GENERIC does have it as a module so 'kldload aio' or >>>> 'aio_load=YES' in loader.conf works for folks who need it. >>>> >>> >>> The same could be said about many other drivers that are in >>> GENERIC _kernel_. So, what was your point? :-) >> >> I don't think aio was out of GENERIC because it wasn't locked >> IIRC, just that it had few users. Is there any popular software >> that uses it? >> > nginx does use it. Not by default though. > Samba can actually get a huge performance boost from using it. There was something broken kernel wise the last time I tried to use it in -current, but I don't recall what that was. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAZNjUACgkQrDN5kXnx8ybBRgCff6AuJgd0D2sk2mbZ/Yih1LBP 1HwAoI+fuuQLx11sq41ajQ/TuNpj6mwy =XBI+ -----END PGP SIGNATURE----- From owner-freebsd-arch@FreeBSD.ORG Wed Aug 1 14:12:10 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 86A41106566B for ; Wed, 1 Aug 2012 14:12:10 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 0F9F88FC14 for ; Wed, 1 Aug 2012 14:12:09 +0000 (UTC) Received: by wgbds11 with SMTP id ds11so6693655wgb.31 for ; Wed, 01 Aug 2012 07:12:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=LJzilumxs80a/tGBTjaRMEg84t9DJ06vpu6GqnlGC7k=; b=ovJGCkY9S5QyBKeipZQ28hU2EVpW9KZkpp+dozT8EIqvSBdM3g6wdua+dWg5GHqQXR ci257DcqJ2EDt3rZleUOfwdIx1g/kBd/ZST3mQNihjv71m6ub88RJWRec3WnebRrn19t rYVbwQHnE7U/lZeDuIbPx5d0jzTT90Dxbv+nydoTLqav7erafbrihr4gq8SmRh2BQ3Ba w+Z3AH9WSZbFkvVcePTZAXShQh3Ds11bFriV4KsjB1ZBSMHR/0S006+ek/Ncsmn+9WYd tJCNe4zCczKe8gurRFCjv6seUyCaZFyU33PPif9Agf0pCv0YWdLK/SUqVKT5DUt028M1 x6ZA== Received: by 10.50.46.232 with SMTP id y8mr5344033igm.57.1343830328145; Wed, 01 Aug 2012 07:12:08 -0700 (PDT) Received: from 63.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id ua2sm6047455igb.7.2012.08.01.07.12.06 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 01 Aug 2012 07:12:07 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <5018E1FC.4080609@gmail.com> Date: Wed, 1 Aug 2012 08:12:06 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5018992C.8000207@freebsd.org> <20120801071934.GJ2676@deviant.kiev.zoral.com.ua> <5018E1FC.4080609@gmail.com> To: davidxu@freebsd.org X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQnDJLTtNw4rt2zskvHhYFGbYNReYGz9CZOpcOzanNkhXwV0v6FZBzFS4mgdesmf1aZwxEza Cc: Konstantin Belousov , arch@freebsd.org Subject: Re: short read/write and error code 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: Wed, 01 Aug 2012 14:12:10 -0000 On Aug 1, 2012, at 1:59 AM, David Xu wrote: > On 2012/8/1 15:19, Konstantin Belousov wrote: >> On Wed, Aug 01, 2012 at 10:49:16AM +0800, David Xu wrote: >>> POSIX requires write() to return actually bytes written, same rule = is >>> applied to read(). >>>=20 >>> http://pubs.opengroup.org/onlinepubs/009695399/functions/write.html >>>> ETURN VALUE >>>>=20 >>>> Upon successful completion, write() [XSI] and pwrite() shall >>>> return the number of bytes actually written to the file associated >>>> with fildes. This number shall never be greater than nbyte. >>>> Otherwise, -1 shall be returned and errno set to indicate the = error. >>>=20 >>> http://pubs.opengroup.org/onlinepubs/009695399/functions/read.html >>>> RETURN VALUE >>>>=20 >>>> Upon successful completion, read() [XSI] and pread() shall = return >>>> a non-negative integer indicating the number of bytes actually = read. >>>> Otherwise, the functions shall return -1 and set errno to indicate >>>> the error. >> Note that the wording is only about successful return, not for the = case >> when error occured. I do think that if fo_read() returned an error, = and >> error is not of the kind 'interruption', then the error shall be = returned >> as is. > I do think data is more important than error code. Do you think if a = 512 bytes block is bad, > all bytes in the block should be thrown away while you could really = get some bytes from it, > this might be very important to someone, such as a password or a bank = account, this > is just an example, whether filesystem works in this way is = irrelevant. You do know that with disk drives it is an all or nothing sort of thing = at the sector level. Either you get the whole thing, or you get none of = it. There's no partial sector reads, and there's no way to get the data = generally. Some drives sometimes allow you to access raw tracks, but = those interfaces are never connected to read, but usually an ioctl that = issues the special command and returns the results. And even then, it = returns everything (perhaps including the ECC bytes) > While program continues to execute, next read()/write() should return = -1 and errno will be > set, I think both socket and pipe already work in this way, it is = dofileread/dofilewrite have > made it not happen. Usually it is up to the driver to make this decision. Most drivers = already return 0 when they've put any data into the buffer. The case = where there's an error returned from the driver and also data indicated = by resid would be vanishingly small. >>> I have following patch to fix our code to be compatible with POSIX: >> ... >>=20 >>> -current only resets error code to zero for short write when code is >>> ERESTART, EINTR or EWOULDBLOCK. >>> But this is incorrect, at least for pipe, when EPIPE is returned, >>> some bytes may have already been written. For a named pipe, I may = don't >>> care a reader is disappeared or not, because for named pipe, a new >>> reader can come in and talk with writer again, so I need to know >>> how many bytes have been written, same is applied to reader, I don't >>> care writer is gone, it can come in again and talk with reader. So I >>> suggest to remove surplus code in -current's dofilewrite() and >>> dofileread(). >> Then fix the pipe code, and not introduce the behaviour change for = all >> file types ? > see above, I think data is more important than error code, and next = read/write will > get the error. >=20 >>> For EPIPE, We still deliver SIGPIPE to current thread, but returns >>> actually bytes written. >> And this sounds wrong. I think that fixing the code for pipes would = also >> semi-magically makes this correct. Yes. Pipes are too magical and don't match devices very well. Warner= From owner-freebsd-arch@FreeBSD.ORG Wed Aug 1 16:28:44 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 827011065670; Wed, 1 Aug 2012 16:28:44 +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 DDB1C8FC0A; Wed, 1 Aug 2012 16:28:43 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q71GSmrQ029370; Wed, 1 Aug 2012 19:28:48 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q71GSa5d073985; Wed, 1 Aug 2012 19:28:36 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q71GSarS073984; Wed, 1 Aug 2012 19:28:36 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 1 Aug 2012 19:28:36 +0300 From: Konstantin Belousov To: Bruce Evans Message-ID: <20120801162836.GO2676@deviant.kiev.zoral.com.ua> References: <5018992C.8000207@freebsd.org> <20120801071934.GJ2676@deviant.kiev.zoral.com.ua> <20120801183240.K1291@besplex.bde.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="uD6Il+FtNNOLHt4d" Content-Disposition: inline In-Reply-To: <20120801183240.K1291@besplex.bde.org> 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=-4.0 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: arch@freebsd.org, David Xu Subject: Re: short read/write and error code 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: Wed, 01 Aug 2012 16:28:44 -0000 --uD6Il+FtNNOLHt4d Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 01, 2012 at 07:23:09PM +1000, Bruce Evans wrote: > On Wed, 1 Aug 2012, Konstantin Belousov wrote: >=20 > >On Wed, Aug 01, 2012 at 10:49:16AM +0800, David Xu wrote: > >>POSIX requires write() to return actually bytes written, same rule is > >>applied to read(). > >> > >>http://pubs.opengroup.org/onlinepubs/009695399/functions/write.html > >>>ETURN VALUE > >>> > >>>Upon successful completion, write() [XSI] and pwrite() shall > >>>return the number of bytes actually written to the file associated > >>>with fildes. This number shall never be greater than nbyte. > >>>Otherwise, -1 shall be returned and errno set to indicate the error. > >> > >>http://pubs.opengroup.org/onlinepubs/009695399/functions/read.html > >>>RETURN VALUE > >>> > >>>Upon successful completion, read() [XSI] and pread() shall return > >>>a non-negative integer indicating the number of bytes actually read. > >>>Otherwise, the functions shall return -1 and set errno to indicate > >>>the error. > >Note that the wording is only about successful return, not for the case > >when error occured. I do think that if fo_read() returned an error, and > >error is not of the kind 'interruption', then the error shall be returned > >as is. >=20 > That is clearly not what is intended. write() is unusable if it won't > tell you how many bytes it wrote. According to your interpretation, > recalcitrantix would conform to POSIX if all it writes wrote whatever > they could and then returned -1 after detecting the error EPOSIXFUZZY. I think this is obvious pull, because no useful implementation would insert _artificial_ error. >=20 > The usability is specified for signals. From an old POSIX draft: >=20 > % 51235 If write( ) is interrupted by a signal before it=20 > writes any data, it shall return -1 with errno set to > % 51236 [EINTR]. > % 51237 If write( ) is interrupted by a signal after it=20 > successfully writes some data, it shall return the > % 51238 number of bytes written. This is exactly what existing code does. >=20 > POSIX formally defines "Successfully Transferred", mainly for aio. I > couldn't find any formal definition of "successfully writes", but clearly > it is nonsense for a write to be unsuccessful if a reader on the local > system or on an external system has successfully read some of the data > written by the write. >=20 > FreeBSD does try to convert EINTR to 0 after some data has been written, > to conform to the above. SIGPIPE should return EINTR to be returned to > dofilewrite(), so there should be no problem for SIGPIPE. But we were > reminded of this old FreeBSD bug by probelms with SIGPIPE. Sorry, I do not understand this, esp. second sentence. As I said, patch behaviour in regard of SIGPIPE is just wrong. >=20 > POSIX contradicts itself by disallowing successful completion if _any_ > error is detected: >=20 > % 435 RETURN VALUE > % 436 This section indicates the possible return= =20 > values, if any. > % 437 If the implementation can detect errors,=20 > ``successful completion'' means that no error > % 438 has been detected during execution of the=20 > function. If the implementation does detect >=20 > Relcalcitrantix has 2 versions according to which of these contradictions > has precedence. In one version, writes do as much as possible before > returning -1/EPOSIXFUZZY, as above. In the other version, this still > happens for most writes. But ones that are interrupted by a signal after > having written some data return the number of bytes written, accoding to > the "shall" for the interrupted case. Perhaps there are some other weird > cases where writes are required to work :-). >=20 > >>I have following patch to fix our code to be compatible with POSIX: > >... > > > >>-current only resets error code to zero for short write when code is > >>ERESTART, EINTR or EWOULDBLOCK. > >>But this is incorrect, at least for pipe, when EPIPE is returned, > >>some bytes may have already been written. For a named pipe, I may don't > >>care a reader is disappeared or not, because for named pipe, a new > >>reader can come in and talk with writer again, so I need to know > >>how many bytes have been written, same is applied to reader, I don't > >>care writer is gone, it can come in again and talk with reader. So I > >>suggest to remove surplus code in -current's dofilewrite() and > >>dofileread(). > >Then fix the pipe code, and not introduce the behaviour change for all > >file types ? >=20 > Because returning the error to userland breaks all file types that > want to return a short i/o (mainly special files whose i/o cannot be > backed out of). They are just detecting and returning an error as a > courtesy to upper layers, and to simplify the implementation. The > syscall API doesn't permit returning both the error code (the reason > for the short i/o) and the short count, so the error code must be > cleared to allow the short count to be returned. No, there is the only sane behaviour for the fo_read and fo_write, to return either no error (or interruption error) and adjust resid, or return error. Returning both error and adjusting resid is just wrong. Proposed patch makes generic i/o layer much less flexible, and probably preventing implementation of things like transactional writes. We should fix sys_pipe.c and not require filesystems to roll back uio into inconsistent state to report errors (since rolling back into consistent state is typically impossible but is required after the patch). >=20 > Bruce --uD6Il+FtNNOLHt4d Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlAZWTQACgkQC3+MBN1Mb4ieaACg5Jt2PwJqw/VtVZ7ovRPGbUZw ec0AniWjpRP6WRWOaXO9GZxEGZAiJy2M =D1/n -----END PGP SIGNATURE----- --uD6Il+FtNNOLHt4d-- From owner-freebsd-arch@FreeBSD.ORG Wed Aug 1 18:05:14 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BF5BB106566C; Wed, 1 Aug 2012 18:05:14 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from fallbackmx10.syd.optusnet.com.au (fallbackmx10.syd.optusnet.com.au [211.29.132.251]) by mx1.freebsd.org (Postfix) with ESMTP id 549A78FC19; Wed, 1 Aug 2012 18:05:13 +0000 (UTC) Received: from mail13.syd.optusnet.com.au (mail13.syd.optusnet.com.au [211.29.132.194]) by fallbackmx10.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q71I56U0018742; Thu, 2 Aug 2012 04:05:06 +1000 Received: from c122-106-171-246.carlnfd1.nsw.optusnet.com.au (c122-106-171-246.carlnfd1.nsw.optusnet.com.au [122.106.171.246]) by mail13.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q71I4rtY007503 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Aug 2012 04:04:56 +1000 Date: Thu, 2 Aug 2012 04:04:53 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Warner Losh In-Reply-To: Message-ID: <20120802032158.S2978@besplex.bde.org> References: <5018992C.8000207@freebsd.org> <20120801071934.GJ2676@deviant.kiev.zoral.com.ua> <5018E1FC.4080609@gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Konstantin Belousov , arch@freebsd.org, davidxu@freebsd.org Subject: Re: short read/write and error code 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: Wed, 01 Aug 2012 18:05:14 -0000 On Wed, 1 Aug 2012, Warner Losh wrote: > On Aug 1, 2012, at 1:59 AM, David Xu wrote: > >> On 2012/8/1 15:19, Konstantin Belousov wrote: >>> On Wed, Aug 01, 2012 at 10:49:16AM +0800, David Xu wrote: Please trim quotes. >>>> ...[some trimmed] >>>> http://pubs.opengroup.org/onlinepubs/009695399/functions/read.html >>>>> RETURN VALUE >>>>> >>>>> Upon successful completion, read() [XSI] and pread() shall return >>>>> a non-negative integer indicating the number of bytes actually read. >>>>> Otherwise, the functions shall return -1 and set errno to indicate >>>>> the error. >>> Note that the wording is only about successful return, not for the case >>> when error occured. I do think that if fo_read() returned an error, and >>> error is not of the kind 'interruption', then the error shall be returned >>> as is. >> I do think data is more important than error code. Do you think if a 512 bytes block is bad, >> all bytes in the block should be thrown away while you could really get some bytes from it, >> this might be very important to someone, such as a password or a bank account, this >> is just an example, whether filesystem works in this way is irrelevant. > > You do know that with disk drives it is an all or nothing sort of thing at the sector level. Either you get the whole thing, or you get none of it. There's no partial sector reads, and there's no way to get the data generally. Some drives sometimes allow you to access raw tracks, but those interfaces are never connected to read, but usually an ioctl that issues the special command and returns the results. And even then, it returns everything (perhaps including the ECC bytes) Please use the Unix newline character. This (the above this, not the Unix newline character) makes the upper-level error handling a non-problem for partial blocks. Disk drives are also directly addressable, so they can sometimes back out of writes (unwrite all successfully written data), like for regular files. >> While program continues to execute, next read()/write() should return -1 and errno will be >> set, I think both socket and pipe already work in this way, it is dofileread/dofilewrite have >> made it not happen. > > Usually it is up to the driver to make this decision. Most drivers already return 0 when they've put any data into the buffer. The case where there's an error returned from the driver and also data indicated by resid would be vanishingly small. I hope most drivers aren't that broken. Backing out of a transfer is hard. Most drivers don't even know that they should. OTOH, they also don't know how much they wrote, so depending on them returning the correct count of what they wrote is dangerous. Normal practice seems to be to uiomove() to a buffer and then start sending the buffer to the hardware. If the latter fails in the middle, then many drivers don't know exactly where it failed, and most don't uiounmove() the data. If the driver write returned with buffered data still not sent to the hardware, write() must return the count of the amount buffered and another mechanism must be used to report errors. If the driver write blocks waiting for buffer space or the hardware, then failure is more likely to be detected before write() returns. uiounmove() of course doesn't exist. Drivers in sys/dev do a fairly large number of direct accesses to uio_resid, but not many write accesses to it (half of the write accesses to it are in cxgb). >>>> I have following patch to fix our code to be compatible with POSIX: >>> ... >>> Then fix the pipe code, and not introduce the behaviour change for all >>> file types ? >> see above, I think data is more important than error code, and next read/write will >> get the error. >> >>>> For EPIPE, We still deliver SIGPIPE to current thread, but returns >>>> actually bytes written. >>> And this sounds wrong. I think that fixing the code for pipes would also >>> semi-magically makes this correct. > > Yes. Pipes are too magical and don't match devices very well. No. They match devices that can't unread or unwrite data fairly well. They are just a bit simpler because the consumer of the data is local and in software, so you can more easily to see if the written data went out. Bruce From owner-freebsd-arch@FreeBSD.ORG Wed Aug 1 18:58:52 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C4D56106564A; Wed, 1 Aug 2012 18:58:52 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail09.syd.optusnet.com.au (mail09.syd.optusnet.com.au [211.29.132.190]) by mx1.freebsd.org (Postfix) with ESMTP id 5B6C28FC14; Wed, 1 Aug 2012 18:58:52 +0000 (UTC) Received: from c122-106-171-246.carlnfd1.nsw.optusnet.com.au (c122-106-171-246.carlnfd1.nsw.optusnet.com.au [122.106.171.246]) by mail09.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q71IwnlA027585 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Aug 2012 04:58:50 +1000 Date: Thu, 2 Aug 2012 04:58:49 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Konstantin Belousov In-Reply-To: <20120801162836.GO2676@deviant.kiev.zoral.com.ua> Message-ID: <20120802040542.G2978@besplex.bde.org> References: <5018992C.8000207@freebsd.org> <20120801071934.GJ2676@deviant.kiev.zoral.com.ua> <20120801183240.K1291@besplex.bde.org> <20120801162836.GO2676@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@freebsd.org, David Xu Subject: Re: short read/write and error code 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: Wed, 01 Aug 2012 18:58:52 -0000 On Wed, 1 Aug 2012, Konstantin Belousov wrote: > On Wed, Aug 01, 2012 at 07:23:09PM +1000, Bruce Evans wrote: >> On Wed, 1 Aug 2012, Konstantin Belousov wrote: >> >>> On Wed, Aug 01, 2012 at 10:49:16AM +0800, David Xu wrote: > ... >> The usability is specified for signals. From an old POSIX draft: >> >> % 51235 If write( ) is interrupted by a signal before it >> writes any data, it shall return -1 with errno set to >> % 51236 [EINTR]. >> % 51237 If write( ) is interrupted by a signal after it >> successfully writes some data, it shall return the >> % 51238 number of bytes written. > This is exactly what existing code does. Yes, this is one of the few cases that is completely specified (when complications for SA_RESTART are added). >> POSIX formally defines "Successfully Transferred", mainly for aio. I >> couldn't find any formal definition of "successfully writes", but clearly >> it is nonsense for a write to be unsuccessful if a reader on the local >> system or on an external system has successfully read some of the data >> written by the write. >> >> FreeBSD does try to convert EINTR to 0 after some data has been written, >> to conform to the above. SIGPIPE should return EINTR to be returned to >> dofilewrite(), so there should be no problem for SIGPIPE. But we were >> reminded of this old FreeBSD bug by probelms with SIGPIPE. > Sorry, I do not understand this, esp. second sentence. Oops, the second sentence has bad grammar. I meant "generation of SIGPIPE should cause EINTR to be returned to dofilewrite(), so...". What actually happens is that lower-level code returns EPIPE, without generating EINTR, to dofilewrite() (except socket code generates SIGPIPE directly unless this is disabled by a socket option). Then dofilewrite() first fails to see the EINTR because the return code is EPIPE (this happens even for the socket case). Then dofilewrite() generates SIGPIPE, again without changing the error code to EINTR or looping back to pick up the special EINTR handling. This is actually correct -- the error is specified to be EPIPE, not EINTR. (This is similar to what happens for the internally-generated SIGXFSZ -- there is a not-so-special error code for that.) So the above is not completely specified after all. EINTR is not intended to apply when the signal is internally generated (and you could argue that the write is not interrupted by a signal in that case; instead, the write fails and generates the signal, which is how this is implemented). Then since it wasn't interrupted, the clause about returning the amount successfully written doesn't apply either. And since we are failing with error code EPIPE, we aren't returning the amount successfully written. So it is apparently up to the lower-level pipe code to not generate EPIPE if it has written something sucessfully. The wording for most of the specication of EPIPE suggests that this error is for when a there is no reader at the time the write() starts. > As I said, patch behaviour in regard of SIGPIPE is just wrong. It is too simple. >>> Then fix the pipe code, and not introduce the behaviour change for all >>> file types ? >> >> Because returning the error to userland breaks all file types that >> want to return a short i/o (mainly special files whose i/o cannot be >> backed out of). They are just detecting and returning an error as a >> courtesy to upper layers, and to simplify the implementation. The >> syscall API doesn't permit returning both the error code (the reason >> for the short i/o) and the short count, so the error code must be >> cleared to allow the short count to be returned. > No, there is the only sane behaviour for the fo_read and fo_write, to > return either no error (or interruption error) and adjust resid, or > return error. Returning both error and adjusting resid is just wrong. It is the FreeBSD API. > Proposed patch makes generic i/o layer much less flexible, and probably > preventing implementation of things like transactional writes. Lower layers still have the option of clobbering either the error or the count, so that uppor layers can't decide which one to use. But this is bad. The syscall layer is not the only one. Other layers may be able to use both. > We should fix sys_pipe.c and not require filesystems to roll back uio > into inconsistent state to report errors (since rolling back into > consistent state is typically impossible but is required after the patch). Rolling back is often possible, but very file-type dependent. ffs rolls back to the original EOF if the write started at the original EOF. This probably applies to all regular files (except irregular regular files in procfs), using a truncate call from vfs. But this is probably still simpler in individual file systems, since the original EOF position is not really known to vfs. It is precisely because backing out is impossible that write() must return what has been written and not an error. Similarly for read(). About reporting counts of buffered data as having been succesfully written: this is little different from write() returning success for data that has only been written to a buffer. But when an error is detected for the current write(), data that is only buffered and belongs to the current write() should be uiounmove()d if possible. Otherwise, treat this data as done by a previous write and don't flush it. For some file types, e.g., terminals, it is specified that data which was reported as written by write() must be written later and not flushed unless the application asks for this. Bruce From owner-freebsd-arch@FreeBSD.ORG Wed Aug 1 22:02:41 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 97500106566B; Wed, 1 Aug 2012 22:02:41 +0000 (UTC) (envelope-from listlog2011@gmail.com) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 74C538FC17; Wed, 1 Aug 2012 22:02:41 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q71M2dfU009407; Wed, 1 Aug 2012 22:02:40 GMT (envelope-from listlog2011@gmail.com) Message-ID: <5019A77C.4030503@gmail.com> Date: Thu, 02 Aug 2012 06:02:36 +0800 From: David Xu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Warner Losh References: <5018992C.8000207@freebsd.org> <20120801071934.GJ2676@deviant.kiev.zoral.com.ua> <5018E1FC.4080609@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Konstantin Belousov , arch@freebsd.org, davidxu@freebsd.org Subject: Re: short read/write and error code X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: davidxu@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 22:02:41 -0000 On 2012/8/1 22:12, Warner Losh wrote: > On Aug 1, 2012, at 1:59 AM, David Xu wrote: > >> On 2012/8/1 15:19, Konstantin Belousov wrote: >>> On Wed, Aug 01, 2012 at 10:49:16AM +0800, David Xu wrote: >>>> POSIX requires write() to return actually bytes written, same rule is >>>> applied to read(). >>>> >>>> http://pubs.opengroup.org/onlinepubs/009695399/functions/write.html >>>>> ETURN VALUE >>>>> >>>>> Upon successful completion, write() [XSI] and pwrite() shall >>>>> return the number of bytes actually written to the file associated >>>>> with fildes. This number shall never be greater than nbyte. >>>>> Otherwise, -1 shall be returned and errno set to indicate the error. >>>> http://pubs.opengroup.org/onlinepubs/009695399/functions/read.html >>>>> RETURN VALUE >>>>> >>>>> Upon successful completion, read() [XSI] and pread() shall return >>>>> a non-negative integer indicating the number of bytes actually read. >>>>> Otherwise, the functions shall return -1 and set errno to indicate >>>>> the error. >>> Note that the wording is only about successful return, not for the case >>> when error occured. I do think that if fo_read() returned an error, and >>> error is not of the kind 'interruption', then the error shall be returned >>> as is. >> I do think data is more important than error code. Do you think if a 512 bytes block is bad, >> all bytes in the block should be thrown away while you could really get some bytes from it, >> this might be very important to someone, such as a password or a bank account, this >> is just an example, whether filesystem works in this way is irrelevant. > You do know that with disk drives it is an all or nothing sort of thing at the sector level. Either you get the whole thing, or you get none of it. There's no partial sector reads, and there's no way to get the data generally. Some drives sometimes allow you to access raw tracks, but those interfaces are never connected to read, but usually an ioctl that issues the special command and returns the results. And even then, it returns everything (perhaps including the ECC bytes) Sorry, my example is not precise, see blow. >> While program continues to execute, next read()/write() should return -1 and errno will be >> set, I think both socket and pipe already work in this way, it is dofileread/dofilewrite have >> made it not happen. > Usually it is up to the driver to make this decision. Most drivers already return 0 when they've put any data into the buffer. The case where there's an error returned from the driver and also data indicated by resid would be vanishingly small. Okay, driver works in this way, I don't complain. >>>> I have following patch to fix our code to be compatible with POSIX: >>> ... >>> >>>> -current only resets error code to zero for short write when code is >>>> ERESTART, EINTR or EWOULDBLOCK. >>>> But this is incorrect, at least for pipe, when EPIPE is returned, >>>> some bytes may have already been written. For a named pipe, I may don't >>>> care a reader is disappeared or not, because for named pipe, a new >>>> reader can come in and talk with writer again, so I need to know >>>> how many bytes have been written, same is applied to reader, I don't >>>> care writer is gone, it can come in again and talk with reader. So I >>>> suggest to remove surplus code in -current's dofilewrite() and >>>> dofileread(). >>> Then fix the pipe code, and not introduce the behaviour change for all >>> file types ? >> see above, I think data is more important than error code, and next read/write will >> get the error. >> >>>> For EPIPE, We still deliver SIGPIPE to current thread, but returns >>>> actually bytes written. >>> And this sounds wrong. I think that fixing the code for pipes would also >>> semi-magically makes this correct. > Yes. Pipes are too magical and don't match devices very well. Unfortunately, the dofileread and dofilewrite are very high level API, it does not device, it is file oriented API, not device oriented. Let me interpret what's wrong in their code. dofileread requests fo_read to read back data into user space buffer, the user space buffer can be very large. fo_read is an intermediate layer, assume it supports large buffer size, for example, it is file system's interface to read data, or it can be some intermediate code which also supports very large buffer size until max-value of SSIZE_T, at lowest level, they all request device driver to read back data, assume the device driver only supports 16K buffer size, if user gives dofileread a 100M buffer, the intermediate layer will split request into 16K chunks, the intermediate layer repeatedly read 16K bytes, until at the final block, it encountered a problem, and device driver returns EIO error code, the fo_read operation read 100M-16K into buffer, and returned EIO too, then what happens in dofileread ? it will simply return EIO and throw 100M-16K data away. Now because I know how the insane dofileread works, I split 100M read request into small chunk from user space, I request data in 16K chunk each time, I happily get 100M-16K bytes, until at final block, I encountered a problem. I only have 16K bytes can not be read If the lowest layer is a byte stream, I would read 100M-1 bytes back, only lost 1 bytes. I have rescued my data. Isn't the difference is very large ? Same problem is applied to dowritefile, I pass 100M data to dowritefile, it wrote out 100M-16K bytes, and then it tells me that it did not write anything. if it is a byte stream, it wrote 100M-1 bytes, only 1 byte encountered a problem. if my buffer size is 500M, isn't the problem more serious ? I think there could be a sysctl to control how many bytes I/O is important, for me, I would set it to 1, for somebody, the value could be DON'T CARE, dofileread or dofilewrite will return number of bytes I/O have been done if the size of I/O completion is larger than the value, otherwise, it returns error code. > Warner From owner-freebsd-arch@FreeBSD.ORG Wed Aug 1 23:31:56 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3753E1065670; Wed, 1 Aug 2012 23:31:56 +0000 (UTC) (envelope-from listlog2011@gmail.com) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 1E5C68FC19; Wed, 1 Aug 2012 23:31:56 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q71NVrDi021580; Wed, 1 Aug 2012 23:31:54 GMT (envelope-from listlog2011@gmail.com) Message-ID: <5019BC67.9000601@gmail.com> Date: Thu, 02 Aug 2012 07:31:51 +0800 From: David Xu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Bruce Evans References: <5018992C.8000207@freebsd.org> <20120801071934.GJ2676@deviant.kiev.zoral.com.ua> <20120801183240.K1291@besplex.bde.org> <20120801162836.GO2676@deviant.kiev.zoral.com.ua> <20120802040542.G2978@besplex.bde.org> In-Reply-To: <20120802040542.G2978@besplex.bde.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Konstantin Belousov , arch@freebsd.org, David Xu Subject: Re: short read/write and error code X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: davidxu@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 23:31:56 -0000 On 2012/8/2 2:58, Bruce Evans wrote: > On Wed, 1 Aug 2012, Konstantin Belousov wrote: > >> As I said, patch behaviour in regard of SIGPIPE is just wrong. > > It is too simple. The pipe code already reset error code zero if the writer have written all bytes to pipe buffer, it does not return EPIPE even if reader closed the pipe, so SIGPIPE is not sent in the case. The SIGPIPE is only generated for short write, this is an intention, it is for applications which takes no notice of short write, such an application does not check return value from write(), when kernel generates SIGPIPE, the default action is to kill the application, if application setup a sigaction for SIGPIPE, this implies that application knows short write. So the patch is correct when it sees EPIPE code. Regards, David Xu From owner-freebsd-arch@FreeBSD.ORG Thu Aug 2 05:54:11 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 93AF3106564A; Thu, 2 Aug 2012 05:54:11 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail03.syd.optusnet.com.au (mail03.syd.optusnet.com.au [211.29.132.184]) by mx1.freebsd.org (Postfix) with ESMTP id 291438FC14; Thu, 2 Aug 2012 05:54:10 +0000 (UTC) Received: from c122-106-171-246.carlnfd1.nsw.optusnet.com.au (c122-106-171-246.carlnfd1.nsw.optusnet.com.au [122.106.171.246]) by mail03.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q725ruHI017740 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Aug 2012 15:54:00 +1000 Date: Thu, 2 Aug 2012 15:53:56 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: davidxu@freebsd.org In-Reply-To: <5019A77C.4030503@gmail.com> Message-ID: <20120802150009.G870@besplex.bde.org> References: <5018992C.8000207@freebsd.org> <20120801071934.GJ2676@deviant.kiev.zoral.com.ua> <5018E1FC.4080609@gmail.com> <5019A77C.4030503@gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Konstantin Belousov , arch@freebsd.org Subject: Re: short read/write and error code 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: Thu, 02 Aug 2012 05:54:11 -0000 On Thu, 2 Aug 2012, David Xu wrote: > On 2012/8/1 22:12, Warner Losh wrote: >> On Aug 1, 2012, at 1:59 AM, David Xu wrote: Please trim quotes! >[>>>>...] trimmed >> You do know that with disk drives it is an all or nothing sort of thing at >> the sector level. Either you get the whole thing, or you get none of it. >> There's no partial sector reads, and there's no way to get the data >> generally. Some drives sometimes allow you to access raw tracks, but those >> interfaces are never connected to read, but usually an ioctl that issues >> the special command and returns the results. And even then, it returns >> everything (perhaps including the ECC bytes) > Sorry, my example is not precise, see blow. > Unfortunately, the dofileread and dofilewrite are very high level API, it > does not device, > it is file oriented API, not device oriented. Let me interpret what's wrong > in their code. > dofileread requests fo_read to read back data into user space buffer, the > user space buffer > can be very large. fo_read is an intermediate layer, assume it supports > large buffer size, > for example, it is file system's interface to read data, or it can be some > intermediate code > which also supports very large buffer size until max-value of SSIZE_T, at > lowest level, they > all request device driver to read back data, assume the device driver only > supports 16K > buffer size, if user gives dofileread a 100M buffer, the intermediate layer > will split request > into 16K chunks, the intermediate layer repeatedly read 16K bytes, until at > the final block, > it encountered a problem, and device driver returns EIO error code, the > fo_read operation > read 100M-16K into buffer, and returned EIO too, then what happens in > dofileread ? > it will simply return EIO and throw 100M-16K data away. This is a perfect example. All (?) block i/o goes through physio. (This is well obfuscated by #define'ing physread and physwrite as physio and never using physio directly.) Most block devices are disk or tape ones, and most disks go through the additional geom layer(s). All (?) layers follow the FreeBSD API and correctly pass back both the i/o count and the error code for the block that failed, if any. Splitting into blocks of size dev->si_iosize_max occurs in the physio layer. This size defaults to DFLTPHYS (64K), but geom bogusly advertizes that it is always MAXPHYS (128K). Then if the actual device's si_iosize_max is less than MAXPHYS, geom does an additional layer of splitting to get the block size down to whatever the device supports. Broken device drivers might do additional splitting. An error can easily be generated by writing to the end of a disk. This error should be ENOSPC. This error should always happen when the source disk is larger for copying one disk to another using primitive methods like cp or dd. The geom level is or should be smart about this. Modulo breakage, it writes a partial block if a write begins just before the end of a disk and not return an error for this case. The partial block of course must have a size that is a multiple of the disk's block size. If the write is exactly at EOF, then the error should be ENOSPC. If the write is after EOF, then the error should be either ENOSPC or EINVAL. Trimming the final i/o gives a short write with no error like some claim all device drivers should do if the don't want to return the error. But this only works if there is no layering! You can now copy a small 4.5GB disk using primitive methods a single i/o if you have enough RAM (dd if=disk1 of=disk2 bs=8g; 8g gives a safety margin). There might be no real i/o errors. There should be an ENOSPC when EOF is hit on the target. The count of 4.5GB together with the error code ENOSPC should be returned to dofilewrite(). dofilewrite() is broken and returns ENOSPC. It is actually safe to ignore this particular error, and programs like gnu tar always did so. It is the standard way of saying that the whole i/o succeeded, except it tried to overrun EOF. An EIO in the middle couldn't be ignored, and the i/o of many GB should be retried, perhaps very slowly with 512-blocks to locate the failing block(s) (actually retry with a sane block size before that). > Now because I know how the insane dofileread works, I split 100M read > request into small > chunk from user space, I request data in 16K chunk each time, I happily get > 100M-16K > bytes, until at final block, I encountered a problem. I only have 16K bytes > can not be read > > If the lowest layer is a byte stream, I would read 100M-1 bytes back, only > lost 1 bytes. > I have rescued my data. > > Isn't the difference is very large ? Of course, you can try using the large block size first and fall back to a small block size only on error. Works for most block devices but not for pipes or for devices with external connections. > Same problem is applied to dowritefile, I pass 100M data to dowritefile, it > wrote out 100M-16K > bytes, and then it tells me that it did not write anything. if it is a byte > stream, it wrote 100M-1 > bytes, only 1 byte encountered a problem. > > if my buffer size is 500M, isn't the problem more serious ? Now falling back doesn't work for write-once devices, and is difficult for tapes. > I think there could be a sysctl to control how many bytes I/O is important, > for me, I would set it > to 1, for somebody, the value could be DON'T CARE, dofileread or dofilewrite > will return number > of bytes I/O have been done if the size of I/O completion is larger than the > value, otherwise, it > returns error code. No, it should just work. Bruce From owner-freebsd-arch@FreeBSD.ORG Thu Aug 2 07:17:23 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8BA98106564A for ; Thu, 2 Aug 2012 07:17:23 +0000 (UTC) (envelope-from irina@finansy.kiev.ua) Received: from finansy.kiev.ua (finansy.kiev.ua [91.232.21.21]) by mx1.freebsd.org (Postfix) with ESMTP id 256768FC08 for ; Thu, 2 Aug 2012 07:17:23 +0000 (UTC) From: "=?utf-8?B?0JjRgNC40L3QsA==?=" To: "freebsd-arch" MIME-Version: 1.0 Date: Thu, 2 Aug 2012 10:17:12 +0300 Message-Id: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: =?utf-8?b?0KLRgNC4INC30LLQtdC30LTRiyDQvdCwINC+0LTQvdC+0Lkg0YE=?= =?utf-8?b?0YbQtdC90LUu?= 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: Thu, 02 Aug 2012 07:17:23 -0000 =EF=BB=BF=D0=92=D0=9F=D0=95=D0=A0=D0=92=D0=AB=D0=95 =D0=92 =D0=A3=D0=9A= =D0=A0=D0=90=D0=98=D0=9D=D0=95! =D0=A2=D0=A0=D0=98 =D0=97=D0=92=D0=95=D0= =97=D0=94=D0=AB =D0=9D=D0=90 =D0=9E=D0=94=D0=9D=D0=9E=D0=99 =D0=A1=D0=A6= =D0=95=D0=9D=D0=95 =20 =D0=98=D1=82=D0=B0=D0=BA, 26 =D0=BE=D0=BA=D1=82=D1=8F=D0=B1=D1=80=D1=8F= =D1=86=D0=B5=D0=BB=D1=8B=D0=B9 =D0=B4=D0=B5=D0=BD=D1=8C, =D0=B2 =D0=9A= =D0=B8=D0=B5=D0=B2=D0=B5, =D0=B2=D0=BF=D0=B5=D1=80=D0=B2=D1=8B=D0=B5 =D0= =B4=D0=BB=D1=8F =D1=83=D0=BA=D1=80=D0=B0=D0=B8=D0=BD=D1=81=D0=BA=D0=BE= =D0=B9 =D0=BF=D1=83=D0=B1=D0=BB=D0=B8=D0=BA=D0=B8 =D0=BD=D0=B0 =D0=BE=D0= =B4=D0=BD=D0=BE=D0=B9 =D1=81=D1=86=D0=B5=D0=BD=D0=B5 =D0=B2=D1=8B=D1=81= =D1=82=D1=83=D0=BF=D1=8F=D1=82 =D1=82=D1=80=D0=B8 =D0=B3=D1=83=D1=80=D1= =83 =D0=BF=D0=BE =D0=BF=D1=80=D0=BE=D0=B4=D0=B0=D0=B6=D0=B0=D0=BC, =D1= =82=D0=B0=D0=B9=D0=BC-=D0=BC=D0=B5=D0=BD=D0=B5=D0=B4=D0=B6=D0=BC=D0=B5= =D0=BD=D1=82=D1=83 =D0=B8 =D0=BB=D0=B8=D0=B4=D0=B5=D1=80=D1=81=D1=82=D0= =B2=D1=83. =20 =D0=A0=D0=B0=D0=B4=D0=B8=D1=81=D0=BB=D0=B0=D0=B2 =D0=93=D0=B0=D0=BD=D0= =B4=D0=B0=D0=BF=D0=B0=D1=81: =D0=9C=D0=A3=D0=94=D0=A0=D0=9E=D0=A1=D0=A2= =D0=AC =D0=9C=D0=9E=D0=A2=D0=98=D0=92=D0=90=D0=A6=D0=98=D0=98 - =D1=84=D0=BE=D1=80=D0=BC=D1=83=D0=BB=D0=B0 =D0=BC=D0=BE=D1=82=D0=B8=D0= =B2=D0=B0=D1=86=D0=B8=D0=B8 =D1=87=D0=B5=D0=BB=D0=BE=D0=B2=D0=B5=D0=BA= =D0=B0 - =D1=82=D0=B8=D0=BF=D0=BE=D0=B2=D1=8B=D0=B5 =D0=B7=D0=B0=D0=B1=D0=BB=D1= =83=D0=B6=D0=B4=D0=B5=D0=BD=D0=B8=D1=8F =D0=BE=D1=82=D0=BD=D0=BE=D1=81= =D0=B8=D1=82=D0=B5=D0=BB=D1=8C=D0=BD=D0=BE =D0=BC=D0=BE=D1=82=D0=B8=D0= =B2=D0=B0=D1=86=D0=B8=D0=B8 - =D1=82=D0=B0=D0=BA =D0=BD=D0=B0=D0=B7=D1=8B=D0=B2=D0=B0=D0=B5=D0=BC=D0= =B0=D1=8F "=D0=BC=D0=B0=D1=82=D0=B5=D1=80=D0=B8=D0=B0=D0=BB=D1=8C=D0=BD= =D0=B0=D1=8F =D0=BC=D0=BE=D1=82=D0=B8=D0=B2=D0=B0=D1=86=D0=B8=D1=8F" =D0= =B8 =D0=B5=D0=B5 =D0=B2=D1=80=D0=B5=D0=B4 - =D1=82=D0=B8=D0=BF=D1=8B =D0=BC=D0=BE=D1=82=D0=B8=D0=B2=D0=B0=D1=86=D0= =B8=D0=B8 - =D1=86=D0=B5=D0=BB=D0=B8 =D0=B8 =D0=BC=D0=BE=D1=82=D0=B8=D0=B2=D1=8B= - =D1=87=D1=82=D0=BE =D1=83=D0=B1=D0=B8=D0=B2=D0=B0=D0=B5=D1=82 =D0=BC= =D0=BE=D1=82=D0=B8=D0=B2=D0=B0=D1=86=D0=B8=D1=8E - =D1=84=D0=BE=D1=80=D0=BC=D1=83=D0=BB=D0=B0 =D0=A5=D0=B0=D0=BA=D0=BC=D0= =B0=D0=BD=D0=B0 =D0=B8 =D0=9E=D0=BB=D0=B4=D1=85=D0=B5=D0=BC=D0=B0: =D0= =BC=D0=B5=D0=BD=D1=8C=D1=88=D0=B5 =D0=B7=D0=B0=D1=82=D1=80=D0=B0=D1=82= =D1=8B - =D0=B1=D0=BE=D0=BB=D1=8C=D1=88=D0=B5 =D0=9A=D0=9F=D0=94 =20 =D0=93=D0=BB=D0=B5=D0=B1 =D0=90=D1=80=D1=85=D0=B0=D0=BD=D0=B3=D0=B5=D0= =BB=D1=8C=D1=81=D0=BA=D0=B8=D0=B9: =D0=9F=D0=A0=D0=90=D0=92=D0=98=D0=9B= =D0=AC=D0=9D=D0=AB=D0=99 =D0=9E=D0=A2=D0=94=D0=AB=D0=A5 =D0=94=D0=9B=D0= =AF =D0=A2=D0=95=D0=A5 =D0=9A=D0=A2=D0=9E =D0=9C=D0=9D=D0=9E=D0=93=D0=9E= =D0=A0=D0=90=D0=91=D0=9E=D0=A2=D0=90=D0=95=D0=A2 =D0=9D=D0=9E=D0=92=D0=90=D0=AF =D0=9F=D0=A0=D0=9E=D0=93=D0=A0=D0=90=D0= =9C=D0=9C=D0=90! =D0=92=D0=9F=D0=95=D0=A0=D0=92=D0=AB=D0=95 =D0=92 =D0= =A3=D0=9A=D0=A0=D0=90=D0=98=D0=9D=D0=95! - =D0=93=D0=B4=D0=B5 =D0=BD=D0=B0=D0=B9=D1=82=D0=B8 =D1=8D=D0=BD=D0=B5= =D1=80=D0=B3=D0=B8=D1=8E =D0=B4=D0=BB=D1=8F =D1=80=D0=B5=D0=B0=D0=BB=D0= =B8=D0=B7=D0=B0=D1=86=D0=B8=D0=B8 =D0=BD=D0=B0=D1=88=D0=B8=D1=85 =D0=B6= =D0=B8=D0=B7=D0=BD=D0=B5=D0=BD=D0=BD=D1=8B=D1=85 =D1=86=D0=B5=D0=BB=D0= =B5=D0=B9? - =D0=9A=D0=B0=D0=BA =D0=BE=D1=80=D0=B3=D0=B0=D0=BD=D0=B8=D0=B7=D0=BE=D0= =B2=D0=B0=D1=82=D1=8C =D0=BE=D1=82=D0=B4=D1=8B=D1=85, =D1=87=D1=82=D0=BE= =D0=B1=D1=8B =D0=BB=D1=83=D1=87=D1=88=D0=B5 =D0=B2=D0=BE=D1=81=D1=81=D1= =82=D0=B0=D0=BD=D0=BE=D0=B2=D0=B8=D1=82=D1=8C =D1=81=D0=B8=D0=BB=D1=8B= ? - =D0=92=D0=B5=D1=87=D0=B5=D1=80 =D1=80=D0=B0=D0=B1=D0=BE=D1=87=D0=B5=D0= =B3=D0=BE =D0=B4=D0=BD=D1=8F, =D0=B2=D1=8B=D1=85=D0=BE=D0=B4=D0=BD=D1=8B= =D0=B5, =D0=BE=D1=82=D0=BF=D1=83=D1=81=D0=BA - =D1=82=D0=B5=D1=85=D0=BD= =D0=BE=D0=BB=D0=BE=D0=B3=D0=B8=D0=B8 =D1=8D=D1=84=D1=84=D0=B5=D0=BA=D1= =82=D0=B8=D0=B2=D0=BD=D0=BE=D0=B3=D0=BE =D0=BE=D1=82=D0=B4=D1=8B=D1=85= =D0=B0 =D0=B8 =D0=BF=D0=B5=D1=80=D0=B5=D0=BA=D0=BB=D1=8E=D1=87=D0=B5=D0= =BD=D0=B8=D1=8F.=20 =20 =D0=A0=D0=B0=D0=B4=D0=BC=D0=B8=D0=BB=D0=BE =D0=9B=D1=83=D0=BA=D0=B8=D1= =87: 10 =D0=A1=D0=95=D0=9A=D0=A0=D0=95=D0=A2=D0=9E=D0=92 =D0=9F=D0=A0=D0= =9E=D0=94=D0=90=D0=96 - =D0=A2=D1=8B =D0=B4=D0=BE=D0=BB=D0=B6=D0=B5=D0=BD =D0=BF=D1=80=D0=BE= =D0=B4=D0=B0=D1=82=D1=8C =D1=82=D0=BE=D0=BB=D1=8C=D0=BA=D0=BE =D0=BE=D0= =B4=D0=BD=D1=83 =D0=B2=D0=B5=D1=89=D1=8C: =D1=81=D0=B2=D0=BE=D0=B9 =D1= =81=D1=82=D0=B0=D1=82=D1=83=D1=81 - =D0=A2=D1=8B =D0=B4=D0=BE=D0=BB=D0=B6=D0=B5=D0=BD =D0=B4=D0=BE=D0=BD= =D0=B5=D1=81=D1=82=D0=B8 =D0=B4=D0=BE =D0=BA=D0=BB=D0=B8=D0=B5=D0=BD=D1= =82=D0=B0 =D0=BF=D1=80=D0=BE=D1=81=D1=82=D1=83=D1=8E =D0=BF=D1=80=D0=B0= =D0=B2=D0=B4=D1=83: =D1=82=D0=B5=D0=B1=D0=B5 =D0=BE=D1=87=D0=B5=D0=BD=D1= =8C =D0=B2=D1=8B=D0=B3=D0=BE=D0=B4=D0=BD=D0=BE =D1=80=D0=B0=D0=B1=D0=BE= =D1=82=D0=B0=D1=82=D1=8C =D1=87=D0=B5=D1=81=D1=82=D0=BD=D0=BE - =D0=A2=D1=8B =D0=B4=D0=BE=D0=BB=D0=B6=D0=B5=D0=BD =D0=BF=D1=80=D0=BE= =D0=B4=D0=B0=D0=B2=D0=B0=D1=82=D1=8C =D1=82=D0=BE=D0=B3=D0=B4=D0=B0 =D0= =BA=D0=BE=D0=B3=D0=B4=D0=B0 =D0=BD=D0=B0=D0=B4=D0=BE, =D0=B0 =D0=BD=D0= =B5 =D0=B2=D1=81=D0=B5 =D0=B2=D1=80=D0=B5=D0=BC=D1=8F - =D0=A2=D1=8B =D0=B4=D0=BE=D0=BB=D0=B6=D0=B5=D0=BD =D0=B7=D0=B0=D0=BD= =D1=8F=D1=82=D1=8C=D1=81=D1=8F =D1=81=D0=BD=D0=B0=D1=87=D0=B0=D0=BB=D0= =B0 =D0=B2=D0=BD=D1=83=D1=82=D1=80=D0=B5=D0=BD=D0=BD=D0=B8=D0=BC=D0=B8= =D0=BF=D1=80=D0=BE=D0=B4=D0=B0=D0=B6=D0=B0=D0=BC=D0=B8, =D0=B0 =D0=BF= =D0=BE=D1=82=D0=BE=D0=BC =D0=BF=D1=80=D0=BE=D0=B4=D0=B0=D0=B6=D0=B0=D0= =BC=D0=B8 =D1=82=D0=BE=D0=B2=D0=B0=D1=80=D0=BE=D0=B2 =D0=B8 =D1=83=D1=81= =D0=BB=D1=83=D0=B3 =D0=BA=D0=BB=D0=B8=D0=B5=D0=BD=D1=82=D0=B0=D0=BC - =D0=A2=D1=8B =D0=B4=D0=BE=D0=BB=D0=B6=D0=B5=D0=BD =D1=81=D0=B4=D0=B5= =D0=BB=D0=B0=D1=82=D1=8C =D1=82=D0=B0=D0=BA, =D1=87=D1=82=D0=BE=D0=B1=D1= =8B =D0=BA=D0=BB=D0=B8=D0=B5=D0=BD=D1=82 =D0=BD=D0=B5 =D0=BC=D0=BE=D0=B3= =D1=82=D0=B5=D0=B1=D1=8F =D1=81=D1=80=D0=B0=D0=B2=D0=BD=D0=B8=D0=B2=D0= =B0=D1=82=D1=8C =D1=81 =D0=B4=D1=80=D1=83=D0=B3=D0=B8=D0=BC=D0=B8 - =D0=A2=D1=8B =D0=B4=D0=BE=D0=BB=D0=B6=D0=B5=D0=BD =D0=BF=D0=BE=D0=BD= =D0=B8=D0=BC=D0=B0=D1=82=D1=8C, =D1=87=D0=B5=D0=B3=D0=BE =D0=BA=D0=BB=D0= =B8=D0=B5=D0=BD=D1=82 =D0=B1=D0=BE=D0=B8=D1=82=D1=81=D1=8F - =D0=A2=D1=8B =D0=B4=D0=BE=D0=BB=D0=B6=D0=B5=D0=BD =D1=83=D0=BF=D1=80= =D0=B0=D0=B2=D0=BB=D1=8F=D1=82=D1=8C =D0=BE=D0=B6=D0=B8=D0=B4=D0=B0=D0= =BD=D0=B8=D1=8F=D0=BC=D0=B8 =D0=BA=D0=BB=D0=B8=D0=B5=D0=BD=D1=82=D0=B0= - =D0=A2=D1=8B =D0=B4=D0=BE=D0=BB=D0=B6=D0=B5=D0=BD =D0=BE=D1=81=D0=B2= =D0=BE=D0=B8=D1=82=D1=8C =D0=B0=D0=B7=D1=8B =D1=83=D0=BF=D1=80=D0=B0=D0= =B2=D0=BB=D0=B5=D0=BD=D0=B8=D1=8F =D0=BF=D1=80=D0=BE=D0=B5=D0=BA=D1=82= =D0=B0=D0=BC=D0=B8 - =D0=A2=D1=8B =D0=B4=D0=BE=D0=BB=D0=B6=D0=B5=D0=BD =D1=80=D0=B0=D0=B1= =D0=BE=D1=82=D0=B0=D1=82=D1=8C =D0=B8 =D0=B1=D0=BE=D0=BB=D1=8C=D1=88=D0= =B5 =D0=B8 =D0=BF=D0=BE-=D0=B4=D1=80=D1=83=D0=B3=D0=BE=D0=BC=D1=83 - =D0=A1=D1=83=D1=80=D0=BE=D0=B2=D0=BE=D0=B5 =D0=BE=D0=B7=D0=B0=D0=B1=D0= =BE=D1=87=D0=B5=D0=BD=D0=BD=D0=BE=D0=B5 =D0=BB=D0=B8=D1=86=D0=BE - =D0= =BD=D0=B5 =D0=B5=D1=81=D1=82=D1=8C =D0=BF=D1=80=D0=B8=D0=B7=D0=BD=D0=B0= =D0=BA =D0=BF=D1=80=D0=BE=D1=84=D0=B5=D1=81=D1=81=D0=B8=D0=BE=D0=BD=D0= =B0=D0=BB=D0=B8=D0=B7=D0=BC=D0=B0: =D1=83=D0=BB=D1=8B=D0=B1=D0=B0=D0=B9= =D1=81=D1=8F! =20 =D0=91=D1=83=D0=B4=D0=B5=D1=82 =D0=BF=D1=80=D0=BE=D1=85=D0=BE=D0=B4=D0= =B8=D1=82=D1=8C: 26 =D0=BE=D0=BA=D1=82=D1=8F=D0=B1=D1=80=D1=8F. =D0=B3. =D0=9A=D0=B8=D0=B5=D0=B2, President Hotel **** =20 =D0=A1=D1=82=D0=BE=D0=B8=D0=BC=D0=BE=D1=81=D1=82=D1=8C: 1200 - 2000 =D0=B3=D1=80=D0=BD. (=D0=B2 =D0=B7=D0=B0=D0=B2=D0=B8=D1=81= =D0=B8=D0=BC=D0=BE=D1=81=D1=82=D0=B8 =D0=BE=D1=82 =D1=80=D1=8F=D0=B4=D0= =B0) - =D0=B7=D0=B0 =D0=BE=D0=B4=D0=BD=D0=BE=D0=B3=D0=BE =D1=83=D1=87=D0= =B0=D1=81=D1=82=D0=BD=D0=B8=D0=BA=D0=B0. =20 =D0=9D=D0=B0 =D1=8D=D1=82=D0=BE =D0=BE=D0=B1=D1=8F=D0=B7=D0=B0=D1=82=D0= =B5=D0=BB=D1=8C=D0=BD=D0=BE =D0=BD=D1=83=D0=B6=D0=BD=D0=BE =D0=BD=D0=B0= =D0=B9=D1=82=D0=B8 =D0=B2=D1=80=D0=B5=D0=BC=D1=8F!=20 =20 =D0=A1 =D1=83=D0=B2=D0=B0=D0=B6=D0=B5=D0=BD=D0=B8=D0=B5=D0=BC, =D0=9A=D0=BE=D0=B2=D0=B0=D0=BB=D0=B5=D0=B2=D0=B0 =D0=98=D1=80=D0=B8=D0= =BD=D0=B0 =D0=A1=D0=B2=D1=8F=D0=B7=D0=B0=D1=82=D1=8C=D1=81=D1=8F =D1=81 =D0=BD=D0= =B0=D0=BC=D0=B8: 044 221-23-85/221-23-87 info@finansy.kiev.ua www.finansy.kiev.ua =D0=A7=D1=82=D0=BE=D0=B1=D1=8B =D0=BE=D1=82=D0=BA=D0=B0=D0=B7=D0=B0=D1= =82=D1=8C=D1=81=D1=8F =D0=BD=D0=B0=D0=B6=D0=BC=D0=B8=D1=82=D0=B5 delet= e@finansy.kiev.ua From owner-freebsd-arch@FreeBSD.ORG Thu Aug 2 08:36:55 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 78665106564A for ; Thu, 2 Aug 2012 08:36:55 +0000 (UTC) (envelope-from irina@finansy.kiev.ua) Received: from finansy.kiev.ua (finansy.kiev.ua [91.232.21.21]) by mx1.freebsd.org (Postfix) with ESMTP id 0EE758FC08 for ; Thu, 2 Aug 2012 08:36:55 +0000 (UTC) From: "=?utf-8?B?0JjRgNC40L3QsA==?=" To: "arch" MIME-Version: 1.0 Date: Thu, 2 Aug 2012 11:36:44 +0300 Message-Id: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: =?utf-8?b?0KLRgNC4INC30LLQtdC30LTRiyDQvdCwINC+0LTQvdC+0Lkg0YE=?= =?utf-8?b?0YbQtdC90LUu?= 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: Thu, 02 Aug 2012 08:36:55 -0000 =EF=BB=BF=D0=92=D0=9F=D0=95=D0=A0=D0=92=D0=AB=D0=95 =D0=92 =D0=A3=D0=9A= =D0=A0=D0=90=D0=98=D0=9D=D0=95! =D0=A2=D0=A0=D0=98 =D0=97=D0=92=D0=95=D0= =97=D0=94=D0=AB =D0=9D=D0=90 =D0=9E=D0=94=D0=9D=D0=9E=D0=99 =D0=A1=D0=A6= =D0=95=D0=9D=D0=95 =20 =D0=98=D1=82=D0=B0=D0=BA, 26 =D0=BE=D0=BA=D1=82=D1=8F=D0=B1=D1=80=D1=8F= =D1=86=D0=B5=D0=BB=D1=8B=D0=B9 =D0=B4=D0=B5=D0=BD=D1=8C, =D0=B2 =D0=9A= =D0=B8=D0=B5=D0=B2=D0=B5, =D0=B2=D0=BF=D0=B5=D1=80=D0=B2=D1=8B=D0=B5 =D0= =B4=D0=BB=D1=8F =D1=83=D0=BA=D1=80=D0=B0=D0=B8=D0=BD=D1=81=D0=BA=D0=BE= =D0=B9 =D0=BF=D1=83=D0=B1=D0=BB=D0=B8=D0=BA=D0=B8 =D0=BD=D0=B0 =D0=BE=D0= =B4=D0=BD=D0=BE=D0=B9 =D1=81=D1=86=D0=B5=D0=BD=D0=B5 =D0=B2=D1=8B=D1=81= =D1=82=D1=83=D0=BF=D1=8F=D1=82 =D1=82=D1=80=D0=B8 =D0=B3=D1=83=D1=80=D1= =83 =D0=BF=D0=BE =D0=BF=D1=80=D0=BE=D0=B4=D0=B0=D0=B6=D0=B0=D0=BC, =D1= =82=D0=B0=D0=B9=D0=BC-=D0=BC=D0=B5=D0=BD=D0=B5=D0=B4=D0=B6=D0=BC=D0=B5= =D0=BD=D1=82=D1=83 =D0=B8 =D0=BB=D0=B8=D0=B4=D0=B5=D1=80=D1=81=D1=82=D0= =B2=D1=83. =20 =D0=A0=D0=B0=D0=B4=D0=B8=D1=81=D0=BB=D0=B0=D0=B2 =D0=93=D0=B0=D0=BD=D0= =B4=D0=B0=D0=BF=D0=B0=D1=81: =D0=9C=D0=A3=D0=94=D0=A0=D0=9E=D0=A1=D0=A2= =D0=AC =D0=9C=D0=9E=D0=A2=D0=98=D0=92=D0=90=D0=A6=D0=98=D0=98 - =D1=84=D0=BE=D1=80=D0=BC=D1=83=D0=BB=D0=B0 =D0=BC=D0=BE=D1=82=D0=B8=D0= =B2=D0=B0=D1=86=D0=B8=D0=B8 =D1=87=D0=B5=D0=BB=D0=BE=D0=B2=D0=B5=D0=BA= =D0=B0 - =D1=82=D0=B8=D0=BF=D0=BE=D0=B2=D1=8B=D0=B5 =D0=B7=D0=B0=D0=B1=D0=BB=D1= =83=D0=B6=D0=B4=D0=B5=D0=BD=D0=B8=D1=8F =D0=BE=D1=82=D0=BD=D0=BE=D1=81= =D0=B8=D1=82=D0=B5=D0=BB=D1=8C=D0=BD=D0=BE =D0=BC=D0=BE=D1=82=D0=B8=D0= =B2=D0=B0=D1=86=D0=B8=D0=B8 - =D1=82=D0=B0=D0=BA =D0=BD=D0=B0=D0=B7=D1=8B=D0=B2=D0=B0=D0=B5=D0=BC=D0= =B0=D1=8F "=D0=BC=D0=B0=D1=82=D0=B5=D1=80=D0=B8=D0=B0=D0=BB=D1=8C=D0=BD= =D0=B0=D1=8F =D0=BC=D0=BE=D1=82=D0=B8=D0=B2=D0=B0=D1=86=D0=B8=D1=8F" =D0= =B8 =D0=B5=D0=B5 =D0=B2=D1=80=D0=B5=D0=B4 - =D1=82=D0=B8=D0=BF=D1=8B =D0=BC=D0=BE=D1=82=D0=B8=D0=B2=D0=B0=D1=86=D0= =B8=D0=B8 - =D1=86=D0=B5=D0=BB=D0=B8 =D0=B8 =D0=BC=D0=BE=D1=82=D0=B8=D0=B2=D1=8B= - =D1=87=D1=82=D0=BE =D1=83=D0=B1=D0=B8=D0=B2=D0=B0=D0=B5=D1=82 =D0=BC= =D0=BE=D1=82=D0=B8=D0=B2=D0=B0=D1=86=D0=B8=D1=8E - =D1=84=D0=BE=D1=80=D0=BC=D1=83=D0=BB=D0=B0 =D0=A5=D0=B0=D0=BA=D0=BC=D0= =B0=D0=BD=D0=B0 =D0=B8 =D0=9E=D0=BB=D0=B4=D1=85=D0=B5=D0=BC=D0=B0: =D0= =BC=D0=B5=D0=BD=D1=8C=D1=88=D0=B5 =D0=B7=D0=B0=D1=82=D1=80=D0=B0=D1=82= =D1=8B - =D0=B1=D0=BE=D0=BB=D1=8C=D1=88=D0=B5 =D0=9A=D0=9F=D0=94 =20 =D0=93=D0=BB=D0=B5=D0=B1 =D0=90=D1=80=D1=85=D0=B0=D0=BD=D0=B3=D0=B5=D0= =BB=D1=8C=D1=81=D0=BA=D0=B8=D0=B9: =D0=9F=D0=A0=D0=90=D0=92=D0=98=D0=9B= =D0=AC=D0=9D=D0=AB=D0=99 =D0=9E=D0=A2=D0=94=D0=AB=D0=A5 =D0=94=D0=9B=D0= =AF =D0=A2=D0=95=D0=A5 =D0=9A=D0=A2=D0=9E =D0=9C=D0=9D=D0=9E=D0=93=D0=9E= =D0=A0=D0=90=D0=91=D0=9E=D0=A2=D0=90=D0=95=D0=A2 =D0=9D=D0=9E=D0=92=D0=90=D0=AF =D0=9F=D0=A0=D0=9E=D0=93=D0=A0=D0=90=D0= =9C=D0=9C=D0=90! =D0=92=D0=9F=D0=95=D0=A0=D0=92=D0=AB=D0=95 =D0=92 =D0= =A3=D0=9A=D0=A0=D0=90=D0=98=D0=9D=D0=95! - =D0=93=D0=B4=D0=B5 =D0=BD=D0=B0=D0=B9=D1=82=D0=B8 =D1=8D=D0=BD=D0=B5= =D1=80=D0=B3=D0=B8=D1=8E =D0=B4=D0=BB=D1=8F =D1=80=D0=B5=D0=B0=D0=BB=D0= =B8=D0=B7=D0=B0=D1=86=D0=B8=D0=B8 =D0=BD=D0=B0=D1=88=D0=B8=D1=85 =D0=B6= =D0=B8=D0=B7=D0=BD=D0=B5=D0=BD=D0=BD=D1=8B=D1=85 =D1=86=D0=B5=D0=BB=D0= =B5=D0=B9? - =D0=9A=D0=B0=D0=BA =D0=BE=D1=80=D0=B3=D0=B0=D0=BD=D0=B8=D0=B7=D0=BE=D0= =B2=D0=B0=D1=82=D1=8C =D0=BE=D1=82=D0=B4=D1=8B=D1=85, =D1=87=D1=82=D0=BE= =D0=B1=D1=8B =D0=BB=D1=83=D1=87=D1=88=D0=B5 =D0=B2=D0=BE=D1=81=D1=81=D1= =82=D0=B0=D0=BD=D0=BE=D0=B2=D0=B8=D1=82=D1=8C =D1=81=D0=B8=D0=BB=D1=8B= ? - =D0=92=D0=B5=D1=87=D0=B5=D1=80 =D1=80=D0=B0=D0=B1=D0=BE=D1=87=D0=B5=D0= =B3=D0=BE =D0=B4=D0=BD=D1=8F, =D0=B2=D1=8B=D1=85=D0=BE=D0=B4=D0=BD=D1=8B= =D0=B5, =D0=BE=D1=82=D0=BF=D1=83=D1=81=D0=BA - =D1=82=D0=B5=D1=85=D0=BD= =D0=BE=D0=BB=D0=BE=D0=B3=D0=B8=D0=B8 =D1=8D=D1=84=D1=84=D0=B5=D0=BA=D1= =82=D0=B8=D0=B2=D0=BD=D0=BE=D0=B3=D0=BE =D0=BE=D1=82=D0=B4=D1=8B=D1=85= =D0=B0 =D0=B8 =D0=BF=D0=B5=D1=80=D0=B5=D0=BA=D0=BB=D1=8E=D1=87=D0=B5=D0= =BD=D0=B8=D1=8F.=20 =20 =D0=A0=D0=B0=D0=B4=D0=BC=D0=B8=D0=BB=D0=BE =D0=9B=D1=83=D0=BA=D0=B8=D1= =87: 10 =D0=A1=D0=95=D0=9A=D0=A0=D0=95=D0=A2=D0=9E=D0=92 =D0=9F=D0=A0=D0= =9E=D0=94=D0=90=D0=96 - =D0=A2=D1=8B =D0=B4=D0=BE=D0=BB=D0=B6=D0=B5=D0=BD =D0=BF=D1=80=D0=BE= =D0=B4=D0=B0=D1=82=D1=8C =D1=82=D0=BE=D0=BB=D1=8C=D0=BA=D0=BE =D0=BE=D0= =B4=D0=BD=D1=83 =D0=B2=D0=B5=D1=89=D1=8C: =D1=81=D0=B2=D0=BE=D0=B9 =D1= =81=D1=82=D0=B0=D1=82=D1=83=D1=81 - =D0=A2=D1=8B =D0=B4=D0=BE=D0=BB=D0=B6=D0=B5=D0=BD =D0=B4=D0=BE=D0=BD= =D0=B5=D1=81=D1=82=D0=B8 =D0=B4=D0=BE =D0=BA=D0=BB=D0=B8=D0=B5=D0=BD=D1= =82=D0=B0 =D0=BF=D1=80=D0=BE=D1=81=D1=82=D1=83=D1=8E =D0=BF=D1=80=D0=B0= =D0=B2=D0=B4=D1=83: =D1=82=D0=B5=D0=B1=D0=B5 =D0=BE=D1=87=D0=B5=D0=BD=D1= =8C =D0=B2=D1=8B=D0=B3=D0=BE=D0=B4=D0=BD=D0=BE =D1=80=D0=B0=D0=B1=D0=BE= =D1=82=D0=B0=D1=82=D1=8C =D1=87=D0=B5=D1=81=D1=82=D0=BD=D0=BE - =D0=A2=D1=8B =D0=B4=D0=BE=D0=BB=D0=B6=D0=B5=D0=BD =D0=BF=D1=80=D0=BE= =D0=B4=D0=B0=D0=B2=D0=B0=D1=82=D1=8C =D1=82=D0=BE=D0=B3=D0=B4=D0=B0 =D0= =BA=D0=BE=D0=B3=D0=B4=D0=B0 =D0=BD=D0=B0=D0=B4=D0=BE, =D0=B0 =D0=BD=D0= =B5 =D0=B2=D1=81=D0=B5 =D0=B2=D1=80=D0=B5=D0=BC=D1=8F - =D0=A2=D1=8B =D0=B4=D0=BE=D0=BB=D0=B6=D0=B5=D0=BD =D0=B7=D0=B0=D0=BD= =D1=8F=D1=82=D1=8C=D1=81=D1=8F =D1=81=D0=BD=D0=B0=D1=87=D0=B0=D0=BB=D0= =B0 =D0=B2=D0=BD=D1=83=D1=82=D1=80=D0=B5=D0=BD=D0=BD=D0=B8=D0=BC=D0=B8= =D0=BF=D1=80=D0=BE=D0=B4=D0=B0=D0=B6=D0=B0=D0=BC=D0=B8, =D0=B0 =D0=BF= =D0=BE=D1=82=D0=BE=D0=BC =D0=BF=D1=80=D0=BE=D0=B4=D0=B0=D0=B6=D0=B0=D0= =BC=D0=B8 =D1=82=D0=BE=D0=B2=D0=B0=D1=80=D0=BE=D0=B2 =D0=B8 =D1=83=D1=81= =D0=BB=D1=83=D0=B3 =D0=BA=D0=BB=D0=B8=D0=B5=D0=BD=D1=82=D0=B0=D0=BC - =D0=A2=D1=8B =D0=B4=D0=BE=D0=BB=D0=B6=D0=B5=D0=BD =D1=81=D0=B4=D0=B5= =D0=BB=D0=B0=D1=82=D1=8C =D1=82=D0=B0=D0=BA, =D1=87=D1=82=D0=BE=D0=B1=D1= =8B =D0=BA=D0=BB=D0=B8=D0=B5=D0=BD=D1=82 =D0=BD=D0=B5 =D0=BC=D0=BE=D0=B3= =D1=82=D0=B5=D0=B1=D1=8F =D1=81=D1=80=D0=B0=D0=B2=D0=BD=D0=B8=D0=B2=D0= =B0=D1=82=D1=8C =D1=81 =D0=B4=D1=80=D1=83=D0=B3=D0=B8=D0=BC=D0=B8 - =D0=A2=D1=8B =D0=B4=D0=BE=D0=BB=D0=B6=D0=B5=D0=BD =D0=BF=D0=BE=D0=BD= =D0=B8=D0=BC=D0=B0=D1=82=D1=8C, =D1=87=D0=B5=D0=B3=D0=BE =D0=BA=D0=BB=D0= =B8=D0=B5=D0=BD=D1=82 =D0=B1=D0=BE=D0=B8=D1=82=D1=81=D1=8F - =D0=A2=D1=8B =D0=B4=D0=BE=D0=BB=D0=B6=D0=B5=D0=BD =D1=83=D0=BF=D1=80= =D0=B0=D0=B2=D0=BB=D1=8F=D1=82=D1=8C =D0=BE=D0=B6=D0=B8=D0=B4=D0=B0=D0= =BD=D0=B8=D1=8F=D0=BC=D0=B8 =D0=BA=D0=BB=D0=B8=D0=B5=D0=BD=D1=82=D0=B0= - =D0=A2=D1=8B =D0=B4=D0=BE=D0=BB=D0=B6=D0=B5=D0=BD =D0=BE=D1=81=D0=B2= =D0=BE=D0=B8=D1=82=D1=8C =D0=B0=D0=B7=D1=8B =D1=83=D0=BF=D1=80=D0=B0=D0= =B2=D0=BB=D0=B5=D0=BD=D0=B8=D1=8F =D0=BF=D1=80=D0=BE=D0=B5=D0=BA=D1=82= =D0=B0=D0=BC=D0=B8 - =D0=A2=D1=8B =D0=B4=D0=BE=D0=BB=D0=B6=D0=B5=D0=BD =D1=80=D0=B0=D0=B1= =D0=BE=D1=82=D0=B0=D1=82=D1=8C =D0=B8 =D0=B1=D0=BE=D0=BB=D1=8C=D1=88=D0= =B5 =D0=B8 =D0=BF=D0=BE-=D0=B4=D1=80=D1=83=D0=B3=D0=BE=D0=BC=D1=83 - =D0=A1=D1=83=D1=80=D0=BE=D0=B2=D0=BE=D0=B5 =D0=BE=D0=B7=D0=B0=D0=B1=D0= =BE=D1=87=D0=B5=D0=BD=D0=BD=D0=BE=D0=B5 =D0=BB=D0=B8=D1=86=D0=BE - =D0= =BD=D0=B5 =D0=B5=D1=81=D1=82=D1=8C =D0=BF=D1=80=D0=B8=D0=B7=D0=BD=D0=B0= =D0=BA =D0=BF=D1=80=D0=BE=D1=84=D0=B5=D1=81=D1=81=D0=B8=D0=BE=D0=BD=D0= =B0=D0=BB=D0=B8=D0=B7=D0=BC=D0=B0: =D1=83=D0=BB=D1=8B=D0=B1=D0=B0=D0=B9= =D1=81=D1=8F! =20 =D0=91=D1=83=D0=B4=D0=B5=D1=82 =D0=BF=D1=80=D0=BE=D1=85=D0=BE=D0=B4=D0= =B8=D1=82=D1=8C: 26 =D0=BE=D0=BA=D1=82=D1=8F=D0=B1=D1=80=D1=8F. =D0=B3. =D0=9A=D0=B8=D0=B5=D0=B2, President Hotel **** =20 =D0=A1=D1=82=D0=BE=D0=B8=D0=BC=D0=BE=D1=81=D1=82=D1=8C: 1200 - 2000 =D0=B3=D1=80=D0=BD. (=D0=B2 =D0=B7=D0=B0=D0=B2=D0=B8=D1=81= =D0=B8=D0=BC=D0=BE=D1=81=D1=82=D0=B8 =D0=BE=D1=82 =D1=80=D1=8F=D0=B4=D0= =B0) - =D0=B7=D0=B0 =D0=BE=D0=B4=D0=BD=D0=BE=D0=B3=D0=BE =D1=83=D1=87=D0= =B0=D1=81=D1=82=D0=BD=D0=B8=D0=BA=D0=B0. =20 =D0=9D=D0=B0 =D1=8D=D1=82=D0=BE =D0=BE=D0=B1=D1=8F=D0=B7=D0=B0=D1=82=D0= =B5=D0=BB=D1=8C=D0=BD=D0=BE =D0=BD=D1=83=D0=B6=D0=BD=D0=BE =D0=BD=D0=B0= =D0=B9=D1=82=D0=B8 =D0=B2=D1=80=D0=B5=D0=BC=D1=8F!=20 =20 =D0=A1 =D1=83=D0=B2=D0=B0=D0=B6=D0=B5=D0=BD=D0=B8=D0=B5=D0=BC, =D0=9A=D0=BE=D0=B2=D0=B0=D0=BB=D0=B5=D0=B2=D0=B0 =D0=98=D1=80=D0=B8=D0= =BD=D0=B0 =D0=A1=D0=B2=D1=8F=D0=B7=D0=B0=D1=82=D1=8C=D1=81=D1=8F =D1=81 =D0=BD=D0= =B0=D0=BC=D0=B8: 044 221-23-85/221-23-87 info@finansy.kiev.ua www.finansy.kiev.ua =D0=A7=D1=82=D0=BE=D0=B1=D1=8B =D0=BE=D1=82=D0=BA=D0=B0=D0=B7=D0=B0=D1= =82=D1=8C=D1=81=D1=8F =D0=BD=D0=B0=D0=B6=D0=BC=D0=B8=D1=82=D0=B5 delet= e@finansy.kiev.ua From owner-freebsd-arch@FreeBSD.ORG Thu Aug 2 10:03:15 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BC84A106566C; Thu, 2 Aug 2012 10:03:15 +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 23A528FC0A; Thu, 2 Aug 2012 10:03:13 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q72A2qpt059437; Thu, 2 Aug 2012 13:02:52 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q72A2ehc080151; Thu, 2 Aug 2012 13:02:40 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q72A2eZl080150; Thu, 2 Aug 2012 13:02:40 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 2 Aug 2012 13:02:40 +0300 From: Konstantin Belousov To: Bruce Evans Message-ID: <20120802100240.GV2676@deviant.kiev.zoral.com.ua> References: <5018992C.8000207@freebsd.org> <20120801071934.GJ2676@deviant.kiev.zoral.com.ua> <20120801183240.K1291@besplex.bde.org> <20120801162836.GO2676@deviant.kiev.zoral.com.ua> <20120802040542.G2978@besplex.bde.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3j1rCUNxv/n/LAQ6" Content-Disposition: inline In-Reply-To: <20120802040542.G2978@besplex.bde.org> 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=-4.0 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: arch@freebsd.org, David Xu Subject: Re: short read/write and error code 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: Thu, 02 Aug 2012 10:03:15 -0000 --3j1rCUNxv/n/LAQ6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 02, 2012 at 04:58:49AM +1000, Bruce Evans wrote: > On Wed, 1 Aug 2012, Konstantin Belousov wrote: >=20 > >On Wed, Aug 01, 2012 at 07:23:09PM +1000, Bruce Evans wrote: > >>On Wed, 1 Aug 2012, Konstantin Belousov wrote: > >> > >>>On Wed, Aug 01, 2012 at 10:49:16AM +0800, David Xu wrote: > >... > >>The usability is specified for signals. From an old POSIX draft: > >> > >>% 51235 If write( ) is interrupted by a signal before it > >>writes any data, it shall return -1 with errno set to > >>% 51236 [EINTR]. > >>% 51237 If write( ) is interrupted by a signal after it > >>successfully writes some data, it shall return the > >>% 51238 number of bytes written. > >This is exactly what existing code does. >=20 > Yes, this is one of the few cases that is completely specified (when > complications for SA_RESTART are added). >=20 > >>POSIX formally defines "Successfully Transferred", mainly for aio. I > >>couldn't find any formal definition of "successfully writes", but clear= ly > >>it is nonsense for a write to be unsuccessful if a reader on the local > >>system or on an external system has successfully read some of the data > >>written by the write. > >> > >>FreeBSD does try to convert EINTR to 0 after some data has been written, > >>to conform to the above. SIGPIPE should return EINTR to be returned to > >>dofilewrite(), so there should be no problem for SIGPIPE. But we were > >>reminded of this old FreeBSD bug by probelms with SIGPIPE. > >Sorry, I do not understand this, esp. second sentence. >=20 > Oops, the second sentence has bad grammar. I meant "generation of > SIGPIPE should cause EINTR to be returned to dofilewrite(), so...". > What actually happens is that lower-level code returns EPIPE, without > generating EINTR, to dofilewrite() (except socket code generates > SIGPIPE directly unless this is disabled by a socket option). Then > dofilewrite() first fails to see the EINTR because the return code > is EPIPE (this happens even for the socket case). Then dofilewrite() > generates SIGPIPE, again without changing the error code to EINTR or > looping back to pick up the special EINTR handling. This is actually > correct -- the error is specified to be EPIPE, not EINTR. (This is > similar to what happens for the internally-generated SIGXFSZ -- there > is a not-so-special error code for that.) Um, no, I do not see how EINTR could be referenced in this context at all. SUSv4 says quite unambigous that "[EPIPE] An attempt is made to write to a pipe or FIFO that is not open for reading by any process, or that only has one end open. A SIGPIPE signal shall also be sent to the thread." Indeed, POSIX does not specify that we cannot return non-zero (success write) and deliver SIGPIPE, but this is just insane. If SIGPIPE handler returns, the return value from write(2) must be -1 and errno set to EPIPE. For naive programs, which are not aware that stdout can be pipe (i.e. the original target audience of SIGPIPE) not delivering the signal on write(2) which write anything is just fine, since we can make a valid assumption that they would repeat the write, and then get EPIPE/SIGPIPE as intended. Anyway, as I said, I very much dislike making the generic I/O layer decide after the filesystem code, and limiting its ability to report errors. I believe that all what is needed is the patch below, which just fixes a bug in pipe code (obvious after all the discussions). I inspected the pipe_read() and it seems to behave correctly without any change. >=20 > So the above is not completely specified after all. EINTR is not > intended to apply when the signal is internally generated (and you > could argue that the write is not interrupted by a signal in that > case; instead, the write fails and generates the signal, which is how > this is implemented). Then since it wasn't interrupted, the clause > about returning the amount successfully written doesn't apply either. > And since we are failing with error code EPIPE, we aren't returning > the amount successfully written. So it is apparently up to the > lower-level pipe code to not generate EPIPE if it has written > something sucessfully. The wording for most of the specication of > EPIPE suggests that this error is for when a there is no reader at the > time the write() starts. Exactly, this is what I mentioned to David as an alternative approach for the fix, which does not cause screw-up of the generic I/O layer. I just went ahead and implemented the fix, see the patch at the end of message. It was tested with David program. >=20 > >>>Then fix the pipe code, and not introduce the behaviour change for all > >>>file types ? > >> > >>Because returning the error to userland breaks all file types that > >>want to return a short i/o (mainly special files whose i/o cannot be > >>backed out of). They are just detecting and returning an error as a > >>courtesy to upper layers, and to simplify the implementation. The > >>syscall API doesn't permit returning both the error code (the reason > >>for the short i/o) and the short count, so the error code must be > >>cleared to allow the short count to be returned. > >No, there is the only sane behaviour for the fo_read and fo_write, to > >return either no error (or interruption error) and adjust resid, or > >return error. Returning both error and adjusting resid is just wrong. >=20 > It is the FreeBSD API. I do not understand this comment. We have a flexibility in kernel, and why should we hack-patch the wrong behaviour of lower layers instead of fixing bugs ? The 'The FreeBSD KPI' there is (or rather, should be): - return changed resid and set error to 0 - return non-zero error, which causes generic layer to ignore resid changes. Such KPI provides the maximal freedom for the lower layer, without requiring filesystem to try to implement impossible things like uio rollback. diff --git a/sys/kern/sys_pipe.c b/sys/kern/sys_pipe.c index 338256c..1a61b93 100644 --- a/sys/kern/sys_pipe.c +++ b/sys/kern/sys_pipe.c @@ -1286,13 +1286,13 @@ pipe_write(fp, uio, active_cred, flags, td) } =20 /* - * Don't return EPIPE if I/O was successful + * Don't return EPIPE if any byte was written. + * EINTR and other interrupts are handled by generic I/O layer. + * Do not pretend that I/O succeeded for obvious user error + * like EFAULT. */ - if ((wpipe->pipe_buffer.cnt =3D=3D 0) && - (uio->uio_resid =3D=3D 0) && - (error =3D=3D EPIPE)) { + if (uio->uio_resid !=3D orig_resid && error =3D=3D EPIPE) error =3D 0; - } =20 if (error =3D=3D 0) vfs_timestamp(&wpipe->pipe_mtime); --3j1rCUNxv/n/LAQ6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlAaUEAACgkQC3+MBN1Mb4iF0wCfQXXUtGFHS568+KnTpNyEbO9Q PjcAnRavk88onkBZ1IFASuWVqYvFoMGg =ytEu -----END PGP SIGNATURE----- --3j1rCUNxv/n/LAQ6-- From owner-freebsd-arch@FreeBSD.ORG Thu Aug 2 11:52:18 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B99911065672; Thu, 2 Aug 2012 11:52:18 +0000 (UTC) (envelope-from listlog2011@gmail.com) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 857C58FC08; Thu, 2 Aug 2012 11:52:18 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q72BqEXl040217; Thu, 2 Aug 2012 11:52:15 GMT (envelope-from listlog2011@gmail.com) Message-ID: <501A69EB.9000701@gmail.com> Date: Thu, 02 Aug 2012 19:52:11 +0800 From: David Xu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Konstantin Belousov References: <5018992C.8000207@freebsd.org> <20120801071934.GJ2676@deviant.kiev.zoral.com.ua> <20120801183240.K1291@besplex.bde.org> <20120801162836.GO2676@deviant.kiev.zoral.com.ua> <20120802040542.G2978@besplex.bde.org> <20120802100240.GV2676@deviant.kiev.zoral.com.ua> In-Reply-To: <20120802100240.GV2676@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org, David Xu Subject: Re: short read/write and error code X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: davidxu@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 11:52:18 -0000 On 2012/8/2 18:02, Konstantin Belousov wrote: > diff --git a/sys/kern/sys_pipe.c b/sys/kern/sys_pipe.c > index 338256c..1a61b93 100644 > --- a/sys/kern/sys_pipe.c > +++ b/sys/kern/sys_pipe.c > @@ -1286,13 +1286,13 @@ pipe_write(fp, uio, active_cred, flags, td) > } > > /* > - * Don't return EPIPE if I/O was successful > + * Don't return EPIPE if any byte was written. > + * EINTR and other interrupts are handled by generic I/O layer. > + * Do not pretend that I/O succeeded for obvious user error > + * like EFAULT. > */ > - if ((wpipe->pipe_buffer.cnt == 0) && > - (uio->uio_resid == 0) && > - (error == EPIPE)) { > + if (uio->uio_resid != orig_resid && error == EPIPE) > error = 0; > - } > > if (error == 0) > vfs_timestamp(&wpipe->pipe_mtime); I dislike the patch, if I thought it is right, I would have already submit such a patch. Now let us see why your patch is wore than my version (attached): -current: short write is done, some bytes were sent dofilewrite returns -1, errno is EPIPE dofilewrite sends SIGPIPE application is killed by SIGPIPE -my attached version: short write is done, some bytes were sent dofilewrite return number of bytes sent, errno is zero dofilewrite sends SIGPIPE. application is killed by SIGPIPE -you version: short write is done, some bytes were sent. dofilewrite returns number of bytes sent, errno is zero. dofilewrite does not send SIGPIPE signal application is not killed application does not check return value from write() application thinks it is successful, application does other things, application might begin a bank account transaction. ... application never comes back... my patch is more compatible with -current. if application does not setup a signal handler for SIGPIPE, when short write happens, it is killed, it is same as -current. if the application set up a signal handler for the signal, it always should check the return value from write(), this is how traditional code works. in your patch, short write does not kill application, you can not assume that the application will request a next write() on the pipe, and you hope the second write to kill the application, but there is always exception, the next write does not happen, application works on other things. This is too incompatible with -current. From owner-freebsd-arch@FreeBSD.ORG Thu Aug 2 11:53:55 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D276106566C; Thu, 2 Aug 2012 11:53:55 +0000 (UTC) (envelope-from listlog2011@gmail.com) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E2DB08FC14; Thu, 2 Aug 2012 11:53:54 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q72BrorA040243; Thu, 2 Aug 2012 11:53:51 GMT (envelope-from listlog2011@gmail.com) Message-ID: <501A6A4B.8060209@gmail.com> Date: Thu, 02 Aug 2012 19:53:47 +0800 From: David Xu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: davidxu@freebsd.org References: <5018992C.8000207@freebsd.org> <20120801071934.GJ2676@deviant.kiev.zoral.com.ua> <20120801183240.K1291@besplex.bde.org> <20120801162836.GO2676@deviant.kiev.zoral.com.ua> <20120802040542.G2978@besplex.bde.org> <20120802100240.GV2676@deviant.kiev.zoral.com.ua> <501A69EB.9000701@gmail.com> In-Reply-To: <501A69EB.9000701@gmail.com> Content-Type: multipart/mixed; boundary="------------020705050204070000090402" Cc: Konstantin Belousov , arch@freebsd.org Subject: Re: short read/write and error code X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: davidxu@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 11:53:55 -0000 This is a multi-part message in MIME format. --------------020705050204070000090402 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 2012/8/2 19:52, David Xu wrote: > On 2012/8/2 18:02, Konstantin Belousov wrote: >> diff --git a/sys/kern/sys_pipe.c b/sys/kern/sys_pipe.c >> index 338256c..1a61b93 100644 >> --- a/sys/kern/sys_pipe.c >> +++ b/sys/kern/sys_pipe.c >> @@ -1286,13 +1286,13 @@ pipe_write(fp, uio, active_cred, flags, td) >> } >> /* >> - * Don't return EPIPE if I/O was successful >> + * Don't return EPIPE if any byte was written. >> + * EINTR and other interrupts are handled by generic I/O layer. >> + * Do not pretend that I/O succeeded for obvious user error >> + * like EFAULT. >> */ >> - if ((wpipe->pipe_buffer.cnt == 0) && >> - (uio->uio_resid == 0) && >> - (error == EPIPE)) { >> + if (uio->uio_resid != orig_resid && error == EPIPE) >> error = 0; >> - } >> if (error == 0) >> vfs_timestamp(&wpipe->pipe_mtime); > > I dislike the patch, if I thought it is right, I would have already > submit such > a patch. Now let us see why your patch is wore than my version > (attached): > -current: > short write is done, some bytes were sent > dofilewrite returns -1, errno is EPIPE > dofilewrite sends SIGPIPE > application is killed by SIGPIPE > -my attached version: > short write is done, some bytes were sent > dofilewrite return number of bytes sent, errno is zero > dofilewrite sends SIGPIPE. > application is killed by SIGPIPE > -you version: > short write is done, some bytes were sent. > dofilewrite returns number of bytes sent, errno is zero. > dofilewrite does not send SIGPIPE signal > application is not killed > application does not check return value from write() > application thinks it is successful, application does other things, > application might begin a bank account transaction. > ... > application never comes back... > > my patch is more compatible with -current. if application does not > setup a signal handler for SIGPIPE, when short write happens, it is > killed, > it is same as -current. if the application set up a signal handler for > the signal, > it always should check the return value from write(), this is how > traditional > code works. > > in your patch, short write does not kill application, you can not assume > that the application will request a next write() on the pipe, and you > hope > the second write to kill the application, but there is always exception, > the next write does not happen, application works on other things. > This is too incompatible with -current. > > Oops, I forgot to attach it. --------------020705050204070000090402 Content-Type: text/plain; charset=gb18030; name="sys_generic_short_pipe_write.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="sys_generic_short_pipe_write.diff" Index: sys_generic.c =================================================================== --- sys_generic.c (revision 238927) +++ sys_generic.c (working copy) @@ -539,15 +539,21 @@ if (fp->f_type == DTYPE_VNODE) bwillwrite(); if ((error = fo_write(fp, auio, td->td_ucred, flags, td))) { - if (auio->uio_resid != cnt && (error == ERESTART || - error == EINTR || error == EWOULDBLOCK)) - error = 0; /* Socket layer is responsible for issuing SIGPIPE. */ if (fp->f_type != DTYPE_SOCKET && error == EPIPE) { PROC_LOCK(td->td_proc); tdsignal(td, SIGPIPE); PROC_UNLOCK(td->td_proc); } + if (auio->uio_resid != cnt) { + if (error == ERESTART || error == EINTR || + error == EWOULDBLOCK) + error = 0; + else if (error == EPIPE && + (fp->f_type == DTYPE_PIPE || + fp->f_type == DTYPE_FIFO)) + error = 0; + } } cnt -= auio->uio_resid; #ifdef KTRACE --------------020705050204070000090402-- From owner-freebsd-arch@FreeBSD.ORG Thu Aug 2 13:51:24 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3206F1065702; Thu, 2 Aug 2012 13:51:24 +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 BCB2B8FC0A; Thu, 2 Aug 2012 13:51:23 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q72DpGMA078621; Thu, 2 Aug 2012 16:51:16 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q72Dp4ku082886; Thu, 2 Aug 2012 16:51:04 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q72Dp3rl082885; Thu, 2 Aug 2012 16:51:03 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 2 Aug 2012 16:51:03 +0300 From: Konstantin Belousov To: davidxu@freebsd.org Message-ID: <20120802135103.GX2676@deviant.kiev.zoral.com.ua> References: <5018992C.8000207@freebsd.org> <20120801071934.GJ2676@deviant.kiev.zoral.com.ua> <20120801183240.K1291@besplex.bde.org> <20120801162836.GO2676@deviant.kiev.zoral.com.ua> <20120802040542.G2978@besplex.bde.org> <20120802100240.GV2676@deviant.kiev.zoral.com.ua> <501A69EB.9000701@gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="H8/LwUd9h7ybXz/g" Content-Disposition: inline In-Reply-To: <501A69EB.9000701@gmail.com> 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=-4.0 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: arch@freebsd.org Subject: Re: short read/write and error code 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: Thu, 02 Aug 2012 13:51:24 -0000 --H8/LwUd9h7ybXz/g Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 02, 2012 at 07:52:11PM +0800, David Xu wrote: > On 2012/8/2 18:02, Konstantin Belousov wrote: > >diff --git a/sys/kern/sys_pipe.c b/sys/kern/sys_pipe.c > >index 338256c..1a61b93 100644 > >--- a/sys/kern/sys_pipe.c > >+++ b/sys/kern/sys_pipe.c > >@@ -1286,13 +1286,13 @@ pipe_write(fp, uio, active_cred, flags, td) > > } > > =20 > > /* > >- * Don't return EPIPE if I/O was successful > >+ * Don't return EPIPE if any byte was written. > >+ * EINTR and other interrupts are handled by generic I/O layer. > >+ * Do not pretend that I/O succeeded for obvious user error > >+ * like EFAULT. > > */ > >- if ((wpipe->pipe_buffer.cnt =3D=3D 0) && > >- (uio->uio_resid =3D=3D 0) && > >- (error =3D=3D EPIPE)) { > >+ if (uio->uio_resid !=3D orig_resid && error =3D=3D EPIPE) > > error =3D 0; > >- } > > =20 > > if (error =3D=3D 0) > > vfs_timestamp(&wpipe->pipe_mtime); >=20 > I dislike the patch, if I thought it is right, I would have already=20 > submit such > a patch. Now let us see why your patch is wore than my version (attached): > -current: > short write is done, some bytes were sent > dofilewrite returns -1, errno is EPIPE > dofilewrite sends SIGPIPE > application is killed by SIGPIPE > -my attached version: > short write is done, some bytes were sent > dofilewrite return number of bytes sent, errno is zero > dofilewrite sends SIGPIPE. > application is killed by SIGPIPE I cannot believe that=20 > -you version: > short write is done, some bytes were sent. > dofilewrite returns number of bytes sent, errno is zero. > dofilewrite does not send SIGPIPE signal > application is not killed > application does not check return value from write() > application thinks it is successful, application does other things, > application might begin a bank account transaction. > ... > application never comes back... And I do think that this behaviour is right. This only different from the CURRENT by the point where the race between writer and exiting reader becomes observable. CURRENT reports that reader side was closed earlier, while my patch pretends that it exited slightly later. >=20 > my patch is more compatible with -current. if application does not > setup a signal handler for SIGPIPE, when short write happens, it is kille= d, > it is same as -current. if the application set up a signal handler for=20 > the signal, > it always should check the return value from write(), this is how=20 > traditional > code works. Now assume that application set the SIGPIPE handler, and did a short write. How can it interpret the delivered signal, if the following syscall return indicates that the write was successful ? Let me repeat myself: there are two objections against your patch. First is the signal generation when no EPIPE is returned to application (observable as I described in the previous paragraph). Second is that having the change in generic i/o layer requires impossible behaviour from the filesystems (ability to roll back failed uio transfer). >=20 > in your patch, short write does not kill application, you can not assume > that the application will request a next write() on the pipe, and you hope > the second write to kill the application, but there is always exception, > the next write does not happen, application works on other things. > This is too incompatible with -current. >=20 This is right behaviour. If the application wrote all data it wanted to wri= te, and went doing something else, then there is no reason to kill it. --H8/LwUd9h7ybXz/g Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlAahccACgkQC3+MBN1Mb4hLPgCgzKLF37K8LPJyRhm8ALtrP+vi GEwAnRHhZPL5T5NXzUfWqnkBPYMPUcFV =WNw2 -----END PGP SIGNATURE----- --H8/LwUd9h7ybXz/g-- From owner-freebsd-arch@FreeBSD.ORG Thu Aug 2 13:54:47 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E5AB4106566C; Thu, 2 Aug 2012 13:54:47 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail03.syd.optusnet.com.au (mail03.syd.optusnet.com.au [211.29.132.184]) by mx1.freebsd.org (Postfix) with ESMTP id 63EC88FC0C; Thu, 2 Aug 2012 13:54:47 +0000 (UTC) Received: from c122-106-171-246.carlnfd1.nsw.optusnet.com.au (c122-106-171-246.carlnfd1.nsw.optusnet.com.au [122.106.171.246]) by mail03.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q72Dsh61021282 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Aug 2012 23:54:45 +1000 Date: Thu, 2 Aug 2012 23:54:43 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Konstantin Belousov In-Reply-To: <20120802100240.GV2676@deviant.kiev.zoral.com.ua> Message-ID: <20120802222245.D2585@besplex.bde.org> References: <5018992C.8000207@freebsd.org> <20120801071934.GJ2676@deviant.kiev.zoral.com.ua> <20120801183240.K1291@besplex.bde.org> <20120801162836.GO2676@deviant.kiev.zoral.com.ua> <20120802040542.G2978@besplex.bde.org> <20120802100240.GV2676@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@freebsd.org, David Xu Subject: Re: short read/write and error code 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: Thu, 02 Aug 2012 13:54:48 -0000 Please trime quotes!! On Thu, 2 Aug 2012, Konstantin Belousov wrote: > On Thu, Aug 02, 2012 at 04:58:49AM +1000, Bruce Evans wrote: >> On Wed, 1 Aug 2012, Konstantin Belousov wrote: >> >>> On Wed, Aug 01, 2012 at 07:23:09PM +1000, Bruce Evans wrote: >>>[>] ... >>>> FreeBSD does try to convert EINTR to 0 after some data has been written, >>>> to conform to the above. SIGPIPE should return EINTR to be returned to >>>> dofilewrite(), so there should be no problem for SIGPIPE. But we were >>>> reminded of this old FreeBSD bug by probelms with SIGPIPE. >>> Sorry, I do not understand this, esp. second sentence. >> >> Oops, the second sentence has bad grammar. I meant "generation of >> SIGPIPE should cause EINTR to be returned to dofilewrite(), so...". >> What actually happens is that lower-level code returns EPIPE, without >> generating EINTR, to dofilewrite() (except socket code generates >> SIGPIPE directly unless this is disabled by a socket option). Then >> dofilewrite() first fails to see the EINTR because the return code >> is EPIPE (this happens even for the socket case). Then dofilewrite() >> generates SIGPIPE, again without changing the error code to EINTR or >> looping back to pick up the special EINTR handling. This is actually >> correct -- the error is specified to be EPIPE, not EINTR. (This is >> similar to what happens for the internally-generated SIGXFSZ -- there >> is a not-so-special error code for that.) > Um, no, I do not see how EINTR could be referenced in this context at all. > SUSv4 says quite unambigous that "[EPIPE] An attempt is made to > write to a pipe or FIFO that is not open for reading by any process, or > that only has one end open. A SIGPIPE signal shall also be sent to the > thread." That's what I said: "the error is specified to be EPIPE, not EINTR". This is somewhat surprising behaviour, and breaks FreeBSD's one working case for short i/o's -- after EINTR -- iff the signal was internally generated. > Indeed, POSIX does not specify that we cannot return non-zero (success > write) and deliver SIGPIPE, but this is just insane. If SIGPIPE handler > returns, the return value from write(2) must be -1 and errno set to > EPIPE. We must return a short write with no SIGPIPE, then SIGPIPE and EPIPE for the next write (without writing anything). > For naive programs, which are not aware that stdout can be > pipe (i.e. the original target audience of SIGPIPE) not delivering the > signal on write(2) which write anything is just fine, since we can > make a valid assumption that they would repeat the write, and then > get EPIPE/SIGPIPE as intended. This is correct for non-naive programs too, but the assumption isn't valid. Non-naive programs don't understand short writes and typically treat them as errors. Except ones that use stdio -- stdio doesn't repeat the whole write, but continues from the point that was successfully written up to. > Anyway, as I said, I very much dislike making the generic I/O layer > decide after the filesystem code, and limiting its ability to report > errors. And I very much dislike losing data to report errors. > I believe that all what is needed is the patch below, which just fixes > a bug in pipe code (obvious after all the discussions). I inspected the > pipe_read() and it seems to behave correctly without any change. >> >> So the above is not completely specified after all. EINTR is not >> intended to apply when the signal is internally generated (and you >> could argue that the write is not interrupted by a signal in that >> case; instead, the write fails and generates the signal, which is how >> this is implemented). Then since it wasn't interrupted, the clause >> ... > Exactly, this is what I mentioned to David as an alternative approach for > the fix, which does not cause screw-up of the generic I/O layer. I just > went ahead and implemented the fix, see the patch at the end of message. > It was tested with David program. It does not fix the generic I/O layer. Fifos aren't very important, but they show the problem with the generic layer. >> It is the FreeBSD API. > I do not understand this comment. We have a flexibility in kernel, and why > should we hack-patch the wrong behaviour of lower layers instead of fixing > bugs ? The FreeBSD API passes up both the success count and the error code, so that splitting up i/o's can work through any number of layers. Then the top layer can't return both, so it must return the most important thing -- the success count. It is not the responsibility of the layer below dofile* to change its correct behaviour because it knows that it is 1 layer below a buggy layer. Most layers don't know their level. > The 'The FreeBSD KPI' there is (or rather, should be): > - return changed resid and set error to 0 Might even work, using only 1000 times as much code and some runtime pessimizations to get the same effect as clearing the error in dofile*. Consider the dofilewrite -> physwrite -> geom_dev -> driver layering. write() tries to write 1M and gets an error on the last 512-block. The i/o is split up something like: - physio: 8 * 128K. 7 succeed and the last fails on the last 512-block. Since something in the last block didn't fail (say just the last 512- block, though in practice the driver would normally use larger blocks and wouldn't know where the error was), and since there is no way to back out of any of the writes (the previous contents of the successfully overwritten blocks has been lost), lower layers should set error to 0 and return the resid changed from 128K down to 512 for the last block. Now we don't see the error and should retry the last 512-block. This time we see the error. Now since there is no way to back out, we should set error to 0 and return 8*128K - 512 for the count. - geom_dev: No problems for first 7*128K. Consider only the last 128K. Assume that it is split again into 2*64K. 1 succeeds and the last fails on the last 512-block. Then we see a short count and retry the 512-block to no avail, as in the physio layer, and eventually return a count of 128K-512 with no error. - driver: Most likely it will try to write the whole 64K, with this failing and the driver not knowing where the failure was. But we are assuming that it knows that only the last 512-block fails, and tells us this. It might retry the 64K-block one 512-block at a time (the old wd driver did this). So eventually it finds that everything except the last 512-block can be written. It returns this to the layer above as usual block clearing error and returning a count of 64K-512. All the layers above retry the failing block to no avail, as the error for it filters up to the top. The 1000 as times as much code is because you have to do this in all drivers. The runtime pessimizations are the useless retries and the executing the extra code to manage this. The end result is that the dofile* layer never sees the error for short i/o's. Unlike other layers, this layer doesn't pretend to understand short i/o's, so it doesn't retry (lower layers could also skip the retry). > - return non-zero error, which causes generic layer to ignore resid changes. > Such KPI provides the maximal freedom for the lower layer, without requiring > filesystem to try to implement impossible things like uio rollback. > > diff --git a/sys/kern/sys_pipe.c b/sys/kern/sys_pipe.c > index 338256c..1a61b93 100644 > --- a/sys/kern/sys_pipe.c > +++ b/sys/kern/sys_pipe.c > @@ -1286,13 +1286,13 @@ pipe_write(fp, uio, active_cred, flags, td) > } > > /* > - * Don't return EPIPE if I/O was successful > + * Don't return EPIPE if any byte was written. > + * EINTR and other interrupts are handled by generic I/O layer. > + * Do not pretend that I/O succeeded for obvious user error > + * like EFAULT. > */ > - if ((wpipe->pipe_buffer.cnt == 0) && > - (uio->uio_resid == 0) && > - (error == EPIPE)) { > + if (uio->uio_resid != orig_resid && error == EPIPE) > error = 0; > - } > > if (error == 0) > vfs_timestamp(&wpipe->pipe_mtime); This is quite reasonable, but it only touches EPIPE for pipes, leaving the general case of EANY for anyfiletype broken. EFAULT is the next easiest error (or even easier) after ENOPSC for testing bugs in this area, since the user can generate it. Consider what happens for an EFAULT on the uio for the last of the 8 128K-blocks in the above (physio seems to actually use memory mapping, not uioread/write()). The first 7 128K-blocks get written irreversibly and you hopefully get EFAULT when mapping the last block. This EFAULT is just as important as EIO, since the underlying file has been changed. Oops, I just rememebered the justification for _not_ returning short writes or backing out of writes in the middle of a regular file. It is that the failing part may have changed the underlying file, and if you return a short write for the successful part then the application will only learn that something fails if it retries the failing part. A failing write means that the whole extent of the region where the write was attempted is indeterminate, and this applies equally to regular files and disk files. Applications just shouldn't attempt to write GBs or TBs at a time, since a failure in the middle leaves them with either no indication of the extent of the error (if a short count is returned) or with the possibility of the whole extent being changed to garbage (if an error is returned). Even in the kernel where bith the count and the error are returned, there is no way to tell how much was turned to garbage beyond the ailure point (this depends on details of the buffering). Retrying in a careful application will eventually find the extent of the error though. The necessary care seems to turn a simple write() call into at least 50 lines of error handling :-(. Bruce From owner-freebsd-arch@FreeBSD.ORG Thu Aug 2 14:18:00 2012 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 2688A10657A3 for ; Thu, 2 Aug 2012 14:18:00 +0000 (UTC) (envelope-from listlog2011@gmail.com) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 0B9318FC12 for ; Thu, 2 Aug 2012 14:18:00 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q72EHtqT059772 for ; Thu, 2 Aug 2012 14:17:58 GMT (envelope-from listlog2011@gmail.com) Message-ID: <501A8C10.6010106@gmail.com> Date: Thu, 02 Aug 2012 22:17:52 +0800 From: David Xu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: freebsd-arch@freebsd.org References: <5018992C.8000207@freebsd.org> <20120801071934.GJ2676@deviant.kiev.zoral.com.ua> <20120801183240.K1291@besplex.bde.org> <20120801162836.GO2676@deviant.kiev.zoral.com.ua> <20120802040542.G2978@besplex.bde.org> <20120802100240.GV2676@deviant.kiev.zoral.com.ua> <501A69EB.9000701@gmail.com> <20120802135103.GX2676@deviant.kiev.zoral.com.ua> In-Reply-To: <20120802135103.GX2676@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: short read/write and error code X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: davidxu@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 14:18:00 -0000 On 2012/8/2 21:51, Konstantin Belousov wrote: > On Thu, Aug 02, 2012 at 07:52:11PM +0800, David Xu wrote: >> On 2012/8/2 18:02, Konstantin Belousov wrote: >>> diff --git a/sys/kern/sys_pipe.c b/sys/kern/sys_pipe.c >>> index 338256c..1a61b93 100644 >>> --- a/sys/kern/sys_pipe.c >>> +++ b/sys/kern/sys_pipe.c >>> @@ -1286,13 +1286,13 @@ pipe_write(fp, uio, active_cred, flags, td) >>> } >>> >>> /* >>> - * Don't return EPIPE if I/O was successful >>> + * Don't return EPIPE if any byte was written. >>> + * EINTR and other interrupts are handled by generic I/O layer. >>> + * Do not pretend that I/O succeeded for obvious user error >>> + * like EFAULT. >>> */ >>> - if ((wpipe->pipe_buffer.cnt == 0) && >>> - (uio->uio_resid == 0) && >>> - (error == EPIPE)) { >>> + if (uio->uio_resid != orig_resid && error == EPIPE) >>> error = 0; >>> - } >>> >>> if (error == 0) >>> vfs_timestamp(&wpipe->pipe_mtime); >> I dislike the patch, if I thought it is right, I would have already >> submit such >> a patch. Now let us see why your patch is wore than my version (attached): >> -current: >> short write is done, some bytes were sent >> dofilewrite returns -1, errno is EPIPE >> dofilewrite sends SIGPIPE >> application is killed by SIGPIPE >> -my attached version: >> short write is done, some bytes were sent >> dofilewrite return number of bytes sent, errno is zero >> dofilewrite sends SIGPIPE. >> application is killed by SIGPIPE > I cannot believe that >> -you version: >> short write is done, some bytes were sent. >> dofilewrite returns number of bytes sent, errno is zero. >> dofilewrite does not send SIGPIPE signal >> application is not killed >> application does not check return value from write() >> application thinks it is successful, application does other things, >> application might begin a bank account transaction. >> ... >> application never comes back... > And I do think that this behaviour is right. This is wrong. An application may don't know a file handle is pipe, because in theory write to a file always successfully, the syscall is blocked until all data is written, an abnormal write (short write) should kill the application, this is how SIGPIPE works, this is the default action. > > This only different from the CURRENT by the point where the race between > writer and exiting reader becomes observable. CURRENT reports that reader > side was closed earlier, while my patch pretends that it exited slightly > later. This is why it is wrong. >> my patch is more compatible with -current. if application does not >> setup a signal handler for SIGPIPE, when short write happens, it is killed, >> it is same as -current. if the application set up a signal handler for >> the signal, >> it always should check the return value from write(), this is how >> traditional >> code works. > Now assume that application set the SIGPIPE handler, and did a short > write. How can it interpret the delivered signal, if the following > syscall return indicates that the write was successful ? check if return value is great than zero and less than the requested, if this is true, it is a short write, don't you check short write when writing code to work with pipe or socket ? do you always think writing to pipe or socket will be successfully ? > Let me repeat myself: there are two objections against your patch. > First is the signal generation when no EPIPE is returned to application > (observable as I described in the previous paragraph). > Second is that having the change in generic i/o layer requires impossible > behaviour from the filesystems (ability to roll back failed uio transfer). >> in your patch, short write does not kill application, you can not assume >> that the application will request a next write() on the pipe, and you hope >> the second write to kill the application, but there is always exception, >> the next write does not happen, application works on other things. >> This is too incompatible with -current. >> > This is right behaviour. If the application wrote all data it wanted to write, > and went doing something else, then there is no reason to kill it. I don't agree. From owner-freebsd-arch@FreeBSD.ORG Thu Aug 2 17:05:38 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C6E6D106564A; Thu, 2 Aug 2012 17:05:38 +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 185148FC15; Thu, 2 Aug 2012 17:05:36 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q72H5dJR097452; Thu, 2 Aug 2012 20:05:39 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q72H5Rsw083858; Thu, 2 Aug 2012 20:05:27 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q72H5Q80083857; Thu, 2 Aug 2012 20:05:26 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 2 Aug 2012 20:05:26 +0300 From: Konstantin Belousov To: Bruce Evans Message-ID: <20120802170526.GC2676@deviant.kiev.zoral.com.ua> References: <5018992C.8000207@freebsd.org> <20120801071934.GJ2676@deviant.kiev.zoral.com.ua> <20120801183240.K1291@besplex.bde.org> <20120801162836.GO2676@deviant.kiev.zoral.com.ua> <20120802040542.G2978@besplex.bde.org> <20120802100240.GV2676@deviant.kiev.zoral.com.ua> <20120802222245.D2585@besplex.bde.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZJ9LQt8cES71PTQH" Content-Disposition: inline In-Reply-To: <20120802222245.D2585@besplex.bde.org> 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=-4.0 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: arch@freebsd.org, David Xu Subject: Re: short read/write and error code 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: Thu, 02 Aug 2012 17:05:38 -0000 --ZJ9LQt8cES71PTQH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 02, 2012 at 11:54:43PM +1000, Bruce Evans wrote: > Please trime quotes!! Should this request be trimmed ? >=20 > On Thu, 2 Aug 2012, Konstantin Belousov wrote: >=20 > >On Thu, Aug 02, 2012 at 04:58:49AM +1000, Bruce Evans wrote: > >>On Wed, 1 Aug 2012, Konstantin Belousov wrote: > We must return a short write with no SIGPIPE, then SIGPIPE and EPIPE for > the next write (without writing anything). Exactly. I really tired arguing about this point with David. He stopped providing any technical reasoning in later conversation, so I stopped replying to him. >=20 > >For naive programs, which are not aware that stdout can be > >pipe (i.e. the original target audience of SIGPIPE) not delivering the > >signal on write(2) which write anything is just fine, since we can > >make a valid assumption that they would repeat the write, and then > >get EPIPE/SIGPIPE as intended. I decided not to trim the paragraph above, possibly getting a reprimand for excessive quoting :). It is too useful for the context. >=20 > This is correct for non-naive programs too, but the assumption isn't > valid. Non-naive programs don't understand short writes and typically > treat them as errors. Except ones that use stdio -- stdio doesn't > repeat the whole write, but continues from the point that was > successfully written up to. Non-naive programs do understand short writes when they expect the file descriptor to not reference regular file. Really good not-naive programs do understand short writes even to supposedly regular files. Do you=20 remember the recent install(1) fix ? >=20 > >Anyway, as I said, I very much dislike making the generic I/O layer > >decide after the filesystem code, and limiting its ability to report > >errors. >=20 > And I very much dislike losing data to report errors. So the bugs with losing data shall be fixed in the filesystems. Otherwise well-behaving filesystems which do return errors only when it is proper to return error are punished. > The 1000 as times as much code is because you have to do this in all > drivers. The runtime pessimizations are the useless retries and the > executing the extra code to manage this. The end result is that the > dofile* layer never sees the error for short i/o's. Unlike other > layers, this layer doesn't pretend to understand short i/o's, so it > doesn't retry (lower layers could also skip the retry). I do not understand why the lower layers need to do retry at all. When appropriate, the layer shall set error to 0 if any advance of resid was performed. This is already done in quite reasonable number of cases. Anyway, this is only important for non-idempotent cases, like non-block devices or pipes. [patch trimmed] >=20 > This is quite reasonable, but it only touches EPIPE for pipes, leaving > the general case of EANY for anyfiletype broken. Yes, this is good, since each case shall be considered and fixed as appropriate. In the case of pipe/fifo, this is actual bug in the sys_pipe.c. Making a hack in dofilewrite() only hides it for write(2), but leaving other users of pipe_write() orphaned. >=20 > EFAULT is the next easiest error (or even easier) after ENOPSC for > testing bugs in this area, since the user can generate it. Consider > what happens for an EFAULT on the uio for the last of the 8 128K-blocks > in the above (physio seems to actually use memory mapping, not > uioread/write()). The first 7 128K-blocks get written irreversibly > and you hopefully get EFAULT when mapping the last block. This EFAULT > is just as important as EIO, since the underlying file has been changed. EFAULT is especially special. EFAULT is user error, and behaviour seems to be undefined by SUSv4 at all for EFAULT. In fact, newnfs and ufs handle EFAULT properly now, returning carefully advanced uio, since deadlock avoidance code relies on this information from the lower layers. >=20 > Oops, I just rememebered the justification for _not_ returning short > writes or backing out of writes in the middle of a regular file. It > is that the failing part may have changed the underlying file, and if > you return a short write for the successful part then the application > will only learn that something fails if it retries the failing part. > A failing write means that the whole extent of the region where the > write was attempted is indeterminate, and this applies equally to > regular files and disk files. Applications just shouldn't attempt to > write GBs or TBs at a time, since a failure in the middle leaves them > with either no indication of the extent of the error (if a short count > is returned) or with the possibility of the whole extent being changed > to garbage (if an error is returned). Even in the kernel where bith > the count and the error are returned, there is no way to tell how much > was turned to garbage beyond the ailure point (this depends on details > of the buffering). Retrying in a careful application will eventually > find the extent of the error though. The necessary care seems to turn > a simple write() call into at least 50 lines of error handling :-(. Yes, the regular files have the nice property of the write idempotence. This is why returning error and not short write (sometimes) is more useful then returning short writes. Examples are indeed EIO, EFAULT or ENXIO. Do not deny the filesystems the right to decide how to handle such situations. --ZJ9LQt8cES71PTQH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlAas1YACgkQC3+MBN1Mb4gK/QCg248SA5XIJk1FbNQV32tXEyrQ UKUAn1+2gJUkwPqkijv26uwjDKlpx/XD =HXic -----END PGP SIGNATURE----- --ZJ9LQt8cES71PTQH-- From owner-freebsd-arch@FreeBSD.ORG Fri Aug 3 01:51:15 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A427A106566B; Fri, 3 Aug 2012 01:51:15 +0000 (UTC) (envelope-from listlog2011@gmail.com) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 890A38FC12; Fri, 3 Aug 2012 01:51:15 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q731pDOa052862; Fri, 3 Aug 2012 01:51:14 GMT (envelope-from listlog2011@gmail.com) Message-ID: <501B2E8E.7090008@gmail.com> Date: Fri, 03 Aug 2012 09:51:10 +0800 From: David Xu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Konstantin Belousov References: <5018992C.8000207@freebsd.org> <20120801071934.GJ2676@deviant.kiev.zoral.com.ua> <20120801183240.K1291@besplex.bde.org> <20120801162836.GO2676@deviant.kiev.zoral.com.ua> <20120802040542.G2978@besplex.bde.org> <20120802100240.GV2676@deviant.kiev.zoral.com.ua> <20120802222245.D2585@besplex.bde.org> <20120802170526.GC2676@deviant.kiev.zoral.com.ua> In-Reply-To: <20120802170526.GC2676@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org, David Xu Subject: Re: short read/write and error code X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: davidxu@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 01:51:15 -0000 On 2012/8/3 1:05, Konstantin Belousov wrote: > On Thu, Aug 02, 2012 at 11:54:43PM +1000, Bruce Evans wrote: >> Please trime quotes!! > Should this request be trimmed ? > >> On Thu, 2 Aug 2012, Konstantin Belousov wrote: >> >>> On Thu, Aug 02, 2012 at 04:58:49AM +1000, Bruce Evans wrote: >>>> On Wed, 1 Aug 2012, Konstantin Belousov wrote: >> We must return a short write with no SIGPIPE, then SIGPIPE and EPIPE for >> the next write (without writing anything). > Exactly. I really tired arguing about this point with David. > He stopped providing any technical reasoning in later conversation, > so I stopped replying to him. I found you were always ignoring what I said about the technical reasoning. You are too arrogant. This is harmful to the project, may drive people away. I agree that you may be good at some programing skill, but you are not God. "generic layer, dont change it,..." or very generalized response, but what can not be changed if it is wrong ? should the bug be kept there forever ? :-( From owner-freebsd-arch@FreeBSD.ORG Sat Aug 4 06:32:35 2012 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C774A106564A; Sat, 4 Aug 2012 06:32:35 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail09.syd.optusnet.com.au (mail09.syd.optusnet.com.au [211.29.132.190]) by mx1.freebsd.org (Postfix) with ESMTP id 5C84D8FC0A; Sat, 4 Aug 2012 06:32:34 +0000 (UTC) Received: from c122-106-171-246.carlnfd1.nsw.optusnet.com.au (c122-106-171-246.carlnfd1.nsw.optusnet.com.au [122.106.171.246]) by mail09.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q746WPXr005666 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 4 Aug 2012 16:32:26 +1000 Date: Sat, 4 Aug 2012 16:32:25 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Konstantin Belousov In-Reply-To: <20120802170526.GC2676@deviant.kiev.zoral.com.ua> Message-ID: <20120804154317.C791@besplex.bde.org> References: <5018992C.8000207@freebsd.org> <20120801071934.GJ2676@deviant.kiev.zoral.com.ua> <20120801183240.K1291@besplex.bde.org> <20120801162836.GO2676@deviant.kiev.zoral.com.ua> <20120802040542.G2978@besplex.bde.org> <20120802100240.GV2676@deviant.kiev.zoral.com.ua> <20120802222245.D2585@besplex.bde.org> <20120802170526.GC2676@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@FreeBSD.org, David Xu Subject: Re: short read/write and error code 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: Sat, 04 Aug 2012 06:32:36 -0000 On Thu, 2 Aug 2012, Konstantin Belousov wrote: I plan to reply to this in more detail, but don't have time and want to slow down this thread. > ... > So the bugs with losing data shall be fixed in the filesystems. > Otherwise well-behaving filesystems which do return errors only when > it is proper to return error are punished. > ... My main point is that this has nothing to do with file systems. It is special files, fifos and many other non-regular files that are the problem. File systems like ffs already reset uio when the return an error. Thus there is (should be) no problem for file systems with clearing `error' at the dofile*() level if uio shows i/o. For special files, it more usually correct to not reset uio, and then it is convenient to not clear `error' until the dofile*() level. I see a problem with this mainly for (seekable r/w) direct access devices (DASDs). These are similar to regular files in a critical respect: suppose you write in the middle of a disk or file and get an i/o error somewhere. Then sometimes, even after writing parts successfully, you (you == the system) have no idea where the error was. The best handling is as in ffs: fail the whole i/o, and reset uio completely. If you know where the error was, and that it didn't corrupt the file (say for EFAULT or ENOSPC), then you can do better and return a short count with no error. ffs doesn't try to do better. When you don't do better, the application has the burden of figuring out where the error was and how much of the file was corrupted. Even when the write was at EOF and ffs has prevented corruption of the file by truncating it to the original EOF, the application still has a difficult task to determine that the file wasn't corrupted, because another application may have moved EOF. Handling EOF perfectly is simpler for DASDs, for both the system and applications (except now st_size doesn't tell applications where it is or was). Reads don't corrupt files, so returning what was read is always good. ffs expects dofileread() to prefer a short count to an error, and breaks the atime when dofileread() is broken: % if ((error == 0 || uio->uio_resid != orig_resid) && We have done i/o even when error != 0, so we test both... % (vp->v_mount->mnt_flag & MNT_NOATIME) == 0 && % (ip->i_flag & IN_ACCESS) == 0) { % VI_LOCK(vp); % ip->i_flag |= IN_ACCESS; ... and mark the atime for update when we have done i/o (also when we done null i/o successfully). % VI_UNLOCK(vp); % } % return (error); Then we return both, expecting dofileread() to prefer the i/o. But dofileread() is broken and prefers the error. Thus the atime is marked for update even when the i/o is backed out of. The above is mostly my code. I fixed it in ~1992 and knew about the bugs in sys_generic.c and hoped to fix them someday. (Some of my tests check that the atime is not updated on errors.) In Net/2 and 4.4BSD-Lite*, ffs_write() marks the atime for update unconditionally at the end. It only has one other return statement in ffs_write() (for EFBIG, for the up-front check of fs_maxfilesize, which is still broken and requires a related fix (POSIX requires short writes up to the max)). Thus in 4.4BSD-Lite2, ffs_write() marks the atime for update on all errors except EFBIG. Oops, that was too many details. Bruce