From owner-freebsd-arch@FreeBSD.ORG Sun Mar 17 00:34:33 2013 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 33BA6F87 for ; Sun, 17 Mar 2013 00:34:33 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (garage.dawidek.net [91.121.88.72]) by mx1.freebsd.org (Postfix) with ESMTP id EF4F59E2 for ; Sun, 17 Mar 2013 00:34:32 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id ACCB7120 for ; Sun, 17 Mar 2013 01:31:10 +0100 (CET) Date: Sun, 17 Mar 2013 01:35:59 +0100 From: Pawel Jakub Dawidek To: freebsd-arch@FreeBSD.org Subject: chflags(2)'s flags argument. Message-ID: <20130317003559.GA1364@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SLDf9lqlvOQaIe6s" Content-Disposition: inline X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Mar 2013 00:34:33 -0000 --SLDf9lqlvOQaIe6s Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi. Currently this is a bit messy: chflags(2) and fchflags(2) take 'flags' argument of type unsigned long and lchflags(2) takes the same argument of type int. At least this is what you can see in manual page and in prototypes of those functions in sys/stat.h. However all of those syscalls are defined in syscalls.master to take the 'flags' argument of type int and this is what they use in kernel. I'd like to proposed the following patch: http://people.freebsd.org/~pjd/patches/chflags_int.patch It changes type of the 'flags' argument from unsigned long to int where possible. I believe this change won't break ABI, as the syscalls (apart from the prototypes) already expect int and I hope in doesn't break API in any really visible and destructive way. If you think otherwise, let me know. Note that the patch doesn't touch the strtofflags(3) function, as I believe it would break ABI and it doesn't touch the fflagstostr(3) function to stay consistent with strtofflags(3). PS. Manual page text provided by jilles. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --SLDf9lqlvOQaIe6s Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlFFD+8ACgkQForvXbEpPzTKWgCeIJol+6BESq0STfoPPrnEZ/Ls WfYAoMNwytFHvNwQ+K6uI/oH6ZGmYnm8 =CzyV -----END PGP SIGNATURE----- --SLDf9lqlvOQaIe6s-- From owner-freebsd-arch@FreeBSD.ORG Sun Mar 17 00:47:36 2013 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5AA76251 for ; Sun, 17 Mar 2013 00:47:36 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (garage.dawidek.net [91.121.88.72]) by mx1.freebsd.org (Postfix) with ESMTP id 22C20A40 for ; Sun, 17 Mar 2013 00:47:35 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id A08DA129 for ; Sun, 17 Mar 2013 01:44:19 +0100 (CET) Date: Sun, 17 Mar 2013 01:49:08 +0100 From: Pawel Jakub Dawidek To: freebsd-arch@FreeBSD.org Subject: chflagsat(2). Message-ID: <20130317004908.GB1364@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IrhDeMKUP4DT/M7F" Content-Disposition: inline X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Mar 2013 00:47:36 -0000 --IrhDeMKUP4DT/M7F Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi. The following patch adds chflagsat(2) syscall to complete other *at syscalls: http://people.freebsd.org/~pjd/patches/chflagsat.patch Note that the name chflagsat was carefully choosen instead of fchflagsat, to not repeat POSIX (more likely Linux) mistakes of using fchmodat, fchownat, futimesat, etc. names when they really shouldn't start with an 'f'. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --IrhDeMKUP4DT/M7F Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlFFEwQACgkQForvXbEpPzSNfQCgwA0PbW5pNLuvTRWte4CiSUAT QEQAn0ndfxE1rUi56S5W2AkSOAZHRR1r =Swr/ -----END PGP SIGNATURE----- --IrhDeMKUP4DT/M7F-- From owner-freebsd-arch@FreeBSD.ORG Sun Mar 17 06:41:35 2013 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E8B61267; Sun, 17 Mar 2013 06:41:35 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 8B42736C; Sun, 17 Mar 2013 06:41:35 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r2H6fNKJ081654; Sun, 17 Mar 2013 08:41:23 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.0 kib.kiev.ua r2H6fNKJ081654 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r2H6fN6q081653; Sun, 17 Mar 2013 08:41:23 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 17 Mar 2013 08:41:23 +0200 From: Konstantin Belousov To: Pawel Jakub Dawidek Subject: Re: chflags(2)'s flags argument. Message-ID: <20130317064123.GM3794@kib.kiev.ua> References: <20130317003559.GA1364@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OuRzA7sCM3dW6CQj" Content-Disposition: inline In-Reply-To: <20130317003559.GA1364@garage.freebsd.pl> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Mar 2013 06:41:36 -0000 --OuRzA7sCM3dW6CQj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Mar 17, 2013 at 01:35:59AM +0100, Pawel Jakub Dawidek wrote: > Hi. >=20 > Currently this is a bit messy: chflags(2) and fchflags(2) take 'flags' > argument of type unsigned long and lchflags(2) takes the same argument > of type int. At least this is what you can see in manual page and in > prototypes of those functions in sys/stat.h. >=20 > However all of those syscalls are defined in syscalls.master to take the > 'flags' argument of type int and this is what they use in kernel. >=20 > I'd like to proposed the following patch: >=20 > http://people.freebsd.org/~pjd/patches/chflags_int.patch >=20 > It changes type of the 'flags' argument from unsigned long to int where > possible. >=20 > I believe this change won't break ABI, as the syscalls (apart from the > prototypes) already expect int and I hope in doesn't break API in any > really visible and destructive way. If you think otherwise, let me know. The patch seems to keep ABI intact for all useful purposes, at least on all architectures the FreeBSD supports. A FreeBSD architecture where sizeof(int) !=3D sizeof(long), uses register calling conventions. Please note that API !=3D ABI, and you found a case where the API is broken indeed by your change. >=20 > Note that the patch doesn't touch the strtofflags(3) function, as I > believe it would break ABI and it doesn't touch the fflagstostr(3) > function to stay consistent with strtofflags(3). >=20 > PS. Manual page text provided by jilles. >=20 > --=20 > Pawel Jakub Dawidek http://www.wheelsystems.com > FreeBSD committer http://www.FreeBSD.org > Am I Evil? Yes, I Am! http://tupytaj.pl --OuRzA7sCM3dW6CQj Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRRWWTAAoJEJDCuSvBvK1BA5cP/jJtC46lftQIL1Ae6ePEcDCx DrWalShTFxAkHYMVAKpu1ZWbdS3sb/r81pgomjI30+8T+pHhpcIxlZ/jcQOBmcoN rBJ2sYif6JBECdHDv1nzpz1aWIEwA/QLVFHD+kwN4z3+38ZZC2ZJJBCP20pPI12x EPzTOuUTkk9jpxSkfziTSU9EdVsU4lSPSKz9aGl7cqPOFVdFOXAYw/zOwYk+6gwW J5lLSnGtRabD8Gf1ub8arJwTKISl9qF8/Gy39f6VbFgR6ni76Iuwate7IF+MLgSK 2BMjxqZl221w8zggGfHQVoqcFZKBkPQqfuF0e3F/uout4iB5siIV69+oHQuxTUmH 7GXhvJhX/4RcsFSJoygCY91uCPi6aUigmviWs74D740bgJo9Z6nc4rID5254ttRE l6BNSef9vHGkNRcjgX8WiyEFDXmrB8/7ML2OsLcKVitsSaUh5cQuSVLW0vxdTsfF txUK+fkAkA4Q8A6GZGILuRiB4v83nZ9AmfCSvXjXYOQ7ZmC2H96bY5W0ELIuqG0G SCfPE7sMO+9kL+tdPql7SmKhGfIr0G1rrZJ46rS37qhjBTQvd2kgCdJbPc3aNjxu 7cldYZ7nREiAp+1/5qMJfDp18oaiiPO8kK+KLeM/6CTtwEoSHrmguDD+BmNUfg/I 0qQhXjDrP4jv2LcaYwmU =JaSa -----END PGP SIGNATURE----- --OuRzA7sCM3dW6CQj-- From owner-freebsd-arch@FreeBSD.ORG Sun Mar 17 06:43:43 2013 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 09463321; Sun, 17 Mar 2013 06:43:43 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 50C9E381; Sun, 17 Mar 2013 06:43:42 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r2H6hc7K081678; Sun, 17 Mar 2013 08:43:38 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.0 kib.kiev.ua r2H6hc7K081678 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r2H6hcl1081677; Sun, 17 Mar 2013 08:43:38 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 17 Mar 2013 08:43:38 +0200 From: Konstantin Belousov To: Pawel Jakub Dawidek Subject: Re: chflagsat(2). Message-ID: <20130317064338.GN3794@kib.kiev.ua> References: <20130317004908.GB1364@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="x8mZJAN2uR61tTGk" Content-Disposition: inline In-Reply-To: <20130317004908.GB1364@garage.freebsd.pl> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Mar 2013 06:43:43 -0000 --x8mZJAN2uR61tTGk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Mar 17, 2013 at 01:49:08AM +0100, Pawel Jakub Dawidek wrote: > Hi. >=20 > The following patch adds chflagsat(2) syscall to complete other *at > syscalls: >=20 > http://people.freebsd.org/~pjd/patches/chflagsat.patch >=20 > Note that the name chflagsat was carefully choosen instead of > fchflagsat, to not repeat POSIX (more likely Linux) mistakes of using > fchmodat, fchownat, futimesat, etc. names when they really shouldn't > start with an 'f'. This is the only point I do not agree with the patch. I prefer to have the syscall name consistent with the other syscalls. --x8mZJAN2uR61tTGk Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRRWYZAAoJEJDCuSvBvK1BYnEP/3Jw70NGv2z4nI+A7wmnsXQq UpJuDrmu6AxSWpIx8qKaRLSeo7eBZ3NCqMu7mqWqFRFHw+JJtjfSFj7apFbTOMcn bi9PsPS3a2vrr4Q9GeTbrza7Smj2ixkPIzwGTBuMI5m7XUuUA2xg5vX7bCb3cskT ErL8BN0ZTBqM7/TyIoe5AAMGL2oAFk6NMp1sxVeAQLgHzO/uGp/lGU3xuPPklRcB TddXjRga4xcWlJuxl3OKrESqGZB77Z2VgxHNfx+4PUkUkv4ZlKRPVmsTqkuAWU+r hkBBhhJMVIqk3CW/MmlThxeXe/t2MKWT97UGVblLWja1bSLfFJF14yZOecX6VL3S XVOHPN11/Qft3nGzs3tCnMQj78yCIig+2BqNgeQ+FXL3uRbWm8Mw+g4OjLesP2Eh R62ytoCTi2xgZ2kTGQWujnPvS+zTNIYz2mP3fBvsk+pNFFVc6C9HPh+XsXdPFKRm LhlaAFUIxg64cSnWpiR7cxykzHpJ3V0H6KA7ABjN12lIRyuZ2VtDqEN+8lsH/MLl xHH7DGLWUc8noFLZQMicnWYAg6ee4stpgd9I9FmiT0sbRVRS2jX5+jCg99FjOaf4 Cs7B+Q/oVPTG23eNOJm2Ns5lf3kibFF2Gxf1ss/gIe81nGTpif+QBWCmeG0YtZwB 6MTl6rWLELz8BL54FkN6 =e6I+ -----END PGP SIGNATURE----- --x8mZJAN2uR61tTGk-- From owner-freebsd-arch@FreeBSD.ORG Sun Mar 17 10:02:28 2013 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 16D132EA; Sun, 17 Mar 2013 10:02:28 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id C30509F7; Sun, 17 Mar 2013 10:02:27 +0000 (UTC) Received: from ds4.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id 4066FB9B1; Sun, 17 Mar 2013 10:02:26 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id E66809A4B; Sun, 17 Mar 2013 11:02:25 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Konstantin Belousov Subject: Re: chflagsat(2). References: <20130317004908.GB1364@garage.freebsd.pl> <20130317064338.GN3794@kib.kiev.ua> Date: Sun, 17 Mar 2013 11:02:24 +0100 In-Reply-To: <20130317064338.GN3794@kib.kiev.ua> (Konstantin Belousov's message of "Sun, 17 Mar 2013 08:43:38 +0200") Message-ID: <86d2uyl4y7.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Mar 2013 10:02:28 -0000 Konstantin Belousov writes: > Pawel Jakub Dawidek writes: > > Note that the name chflagsat was carefully choosen instead of > > fchflagsat, to not repeat POSIX (more likely Linux) mistakes of using > > fchmodat, fchownat, futimesat, etc. names when they really shouldn't > > start with an 'f'. > This is the only point I do not agree with the patch. I prefer to have > the syscall name consistent with the other syscalls. So do I, which is why I agree with Pawel's decision to call it chflagsat() instead of fchflagsat(): int openat(int, const char *, int, ...); int faccessat(int, const char *, int, int); int linkat(int, const char *, int, const char *, int); ssize_t readlinkat(int, const char * __restrict, char * __restrict, size_t); int symlinkat(const char *, int, const char *); int unlinkat(int, const char *, int); etc. Unfortunately, we also have int fchownat(int, const char *, uid_t, gid_t, int); which makes as little sense as fchflagsat(). DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Sun Mar 17 11:09:43 2013 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4108BDB6 for ; Sun, 17 Mar 2013 11:09:43 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (garage.dawidek.net [91.121.88.72]) by mx1.freebsd.org (Postfix) with ESMTP id 00771BEF for ; Sun, 17 Mar 2013 11:09:42 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id 791031ED; Sun, 17 Mar 2013 12:06:24 +0100 (CET) Date: Sun, 17 Mar 2013 12:11:12 +0100 From: Pawel Jakub Dawidek To: Konstantin Belousov Subject: Re: chflags(2)'s flags argument. Message-ID: <20130317111112.GC1364@garage.freebsd.pl> References: <20130317003559.GA1364@garage.freebsd.pl> <20130317064123.GM3794@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gr/z0/N6AeWAPJVB" Content-Disposition: inline In-Reply-To: <20130317064123.GM3794@kib.kiev.ua> X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Mar 2013 11:09:43 -0000 --gr/z0/N6AeWAPJVB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Mar 17, 2013 at 08:41:23AM +0200, Konstantin Belousov wrote: > On Sun, Mar 17, 2013 at 01:35:59AM +0100, Pawel Jakub Dawidek wrote: > > Hi. > >=20 > > Currently this is a bit messy: chflags(2) and fchflags(2) take 'flags' > > argument of type unsigned long and lchflags(2) takes the same argument > > of type int. At least this is what you can see in manual page and in > > prototypes of those functions in sys/stat.h. > >=20 > > However all of those syscalls are defined in syscalls.master to take the > > 'flags' argument of type int and this is what they use in kernel. > >=20 > > I'd like to proposed the following patch: > >=20 > > http://people.freebsd.org/~pjd/patches/chflags_int.patch > >=20 > > It changes type of the 'flags' argument from unsigned long to int where > > possible. > >=20 > > I believe this change won't break ABI, as the syscalls (apart from the > > prototypes) already expect int and I hope in doesn't break API in any > > really visible and destructive way. If you think otherwise, let me know. > The patch seems to keep ABI intact for all useful purposes, at least > on all architectures the FreeBSD supports. A FreeBSD architecture where > sizeof(int) !=3D sizeof(long), uses register calling conventions. Actually I'd rephrase that. If I understand correctly, because we use register calling conventions on architectures where sizeof(int) !=3D sizeof(long), this mess is working correctly now. Remember that syscalls are defined to take int, but prototypes say unsigned long. > Please note that API !=3D ABI, and you found a case where the API > is broken indeed by your change. I know it can break API in some rare cases like in chflags(1), but it results in compilation error (at least with the compilation flags we use), so can be easly spotted and fixed, hopefully: /usr/home/pjd/p4/capkern/bin/chflags/chflags.c: In function 'main': /usr/home/pjd/p4/capkern/bin/chflags/chflags.c:120: warning: assignment fro= m incompatible pointer type --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --gr/z0/N6AeWAPJVB Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlFFpNAACgkQForvXbEpPzT+8gCgzo1eg6NfXRQJU1Qo0zokDwCo bY0Anj1aQRXaww+0C5Tpaau3dLcdhfst =ww9+ -----END PGP SIGNATURE----- --gr/z0/N6AeWAPJVB-- From owner-freebsd-arch@FreeBSD.ORG Sun Mar 17 11:18:00 2013 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 517C5E91 for ; Sun, 17 Mar 2013 11:18:00 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (garage.dawidek.net [91.121.88.72]) by mx1.freebsd.org (Postfix) with ESMTP id 11BE4C1C for ; Sun, 17 Mar 2013 11:17:59 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id 0B3BB1F1; Sun, 17 Mar 2013 12:14:42 +0100 (CET) Date: Sun, 17 Mar 2013 12:19:31 +0100 From: Pawel Jakub Dawidek To: Konstantin Belousov Subject: Re: chflagsat(2). Message-ID: <20130317111931.GD1364@garage.freebsd.pl> References: <20130317004908.GB1364@garage.freebsd.pl> <20130317064338.GN3794@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="fOHHtNG4YXGJ0yqR" Content-Disposition: inline In-Reply-To: <20130317064338.GN3794@kib.kiev.ua> X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Mar 2013 11:18:00 -0000 --fOHHtNG4YXGJ0yqR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Mar 17, 2013 at 08:43:38AM +0200, Konstantin Belousov wrote: > On Sun, Mar 17, 2013 at 01:49:08AM +0100, Pawel Jakub Dawidek wrote: > > Hi. > >=20 > > The following patch adds chflagsat(2) syscall to complete other *at > > syscalls: > >=20 > > http://people.freebsd.org/~pjd/patches/chflagsat.patch > >=20 > > Note that the name chflagsat was carefully choosen instead of > > fchflagsat, to not repeat POSIX (more likely Linux) mistakes of using > > fchmodat, fchownat, futimesat, etc. names when they really shouldn't > > start with an 'f'. >=20 > This is the only point I do not agree with the patch. I prefer to have > the syscall name consistent with the other syscalls. There are quite a few *at() syscalls and only few of them have bogus 'f' prefix (fchmodat, fchownat, fstatat, futimesat). Most of them don't (bindat, connectat, linkat, mkdirat, mkfifoat, mknodat, openat, renameat, symlinkat, unlinkat). 'f' is of course bogus, because the syscalls don't operate on descriptors, but on paths. Also note that POSIX is moving aways from those mistakes and eventhough they standarized futimesat(), they now use utimensat() for nanosecond precision timestamps to stop those mistakes. This is actually the argument jilles' convinced me to use chflagsat instead of fchflagsat, which is originally used. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --fOHHtNG4YXGJ0yqR Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlFFpsMACgkQForvXbEpPzTNuQCg05X9vRhXLwqb4PaSiWyuHmpz EKsAnRKukxsilLbJQUIVN9nZ2BrguQ1B =/X6D -----END PGP SIGNATURE----- --fOHHtNG4YXGJ0yqR-- From owner-freebsd-arch@FreeBSD.ORG Sun Mar 17 15:57:51 2013 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CD95BCAF; Sun, 17 Mar 2013 15:57:51 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 29ABD80E; Sun, 17 Mar 2013 15:57:50 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r2HFviZ8081760; Sun, 17 Mar 2013 17:57:44 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.0 kib.kiev.ua r2HFviZ8081760 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r2HFvhdt081759; Sun, 17 Mar 2013 17:57:43 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 17 Mar 2013 17:57:43 +0200 From: Konstantin Belousov To: Pawel Jakub Dawidek Subject: Re: chflags(2)'s flags argument. Message-ID: <20130317155743.GR3794@kib.kiev.ua> References: <20130317003559.GA1364@garage.freebsd.pl> <20130317064123.GM3794@kib.kiev.ua> <20130317111112.GC1364@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="CFQN6Iaevez+I9dc" Content-Disposition: inline In-Reply-To: <20130317111112.GC1364@garage.freebsd.pl> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Mar 2013 15:57:51 -0000 --CFQN6Iaevez+I9dc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Mar 17, 2013 at 12:11:12PM +0100, Pawel Jakub Dawidek wrote: > On Sun, Mar 17, 2013 at 08:41:23AM +0200, Konstantin Belousov wrote: > > On Sun, Mar 17, 2013 at 01:35:59AM +0100, Pawel Jakub Dawidek wrote: > > > Hi. > > >=20 > > > Currently this is a bit messy: chflags(2) and fchflags(2) take 'flags' > > > argument of type unsigned long and lchflags(2) takes the same argument > > > of type int. At least this is what you can see in manual page and in > > > prototypes of those functions in sys/stat.h. > > >=20 > > > However all of those syscalls are defined in syscalls.master to take = the > > > 'flags' argument of type int and this is what they use in kernel. > > >=20 > > > I'd like to proposed the following patch: > > >=20 > > > http://people.freebsd.org/~pjd/patches/chflags_int.patch > > >=20 > > > It changes type of the 'flags' argument from unsigned long to int whe= re > > > possible. > > >=20 > > > I believe this change won't break ABI, as the syscalls (apart from the > > > prototypes) already expect int and I hope in doesn't break API in any > > > really visible and destructive way. If you think otherwise, let me kn= ow. > > The patch seems to keep ABI intact for all useful purposes, at least > > on all architectures the FreeBSD supports. A FreeBSD architecture where > > sizeof(int) !=3D sizeof(long), uses register calling conventions. >=20 > Actually I'd rephrase that. If I understand correctly, because we use > register calling conventions on architectures where sizeof(int) !=3D > sizeof(long), this mess is working correctly now. Remember that syscalls > are defined to take int, but prototypes say unsigned long. It needs some untangling. The ABI exported by libc is what I care about when referring to the ABI. And this is the ABI which is not broken due to the reason I stated above. The interface exported by the kernel for consumption of the libc syscall wrappers is dufferent from the normal ABI on the architecture. >=20 > > Please note that API !=3D ABI, and you found a case where the API > > is broken indeed by your change. >=20 > I know it can break API in some rare cases like in chflags(1), but it > results in compilation error (at least with the compilation flags we > use), so can be easly spotted and fixed, hopefully: >=20 > /usr/home/pjd/p4/capkern/bin/chflags/chflags.c: In function 'main': > /usr/home/pjd/p4/capkern/bin/chflags/chflags.c:120: warning: assignment f= rom incompatible pointer type >=20 Project aims to maintain better compatibility then to claim that the changes could be 'spotted'. --CFQN6Iaevez+I9dc Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRRef3AAoJEJDCuSvBvK1BYtgP/0xDdOCWPvx1o0SOI7iLZCCK L4qeIWieXqmWKmjDmHnPehj4G/AQAXkVr3+jOvUEHEjiP1gFANy6wSIwPDW8l79n WZDmllfOSFTKGIu5khDLKDX25LaZxRtGQm1CJEbiKBVM5ofXCq/jcBvsu+X+GHTx /xqB31JSLF7Obo6cVOljLE+ZkAO17vLptUBhjuH2D6CdeIw8vX3RUvbyD68rlMgV 16H31ViOuK1WJVVl5IS97hBEtrYILtXye0hr9o9QUOywFhJNoZaqRoqMFbl3TDm4 xP/g1nXEM2ncovkwpx9T3FQVNRk9KzELTpmknyYB42P5WPQhOf2d7ieaPpdjV7be iBgT5XZsj1rXALCbUi703+NO5b5xIhFU0PW2iqA4xG9orDkcVDhmSS+ZOcWIwVPe pj/gjaNV2j/eRSdQvFpOv/epXME4zAO5q6SOs8wMMBNFmM4F5Um3mf1O4VN5o2ak SXnorZ8OJSnrmRR39l7/3cbf+wdv1zX0vOJyDsbh4maPAxJaOWI0mECmXRqSHZO6 r7Fg3GsHIWvLrroS7WDnUp83s7IBdVbTidayesv+8d+iy/VMmjQQuV6ZN9StGCsI pQu9WdBd4dpxi2gKPKLZkXQxJCEov3ijITOFuS8Z28Rcm/7SYdsnBEhHItWB/E2X FM6i1b3u9pmQ73AXfqPZ =vsac -----END PGP SIGNATURE----- --CFQN6Iaevez+I9dc-- From owner-freebsd-arch@FreeBSD.ORG Sun Mar 17 15:59:36 2013 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 69DD9DE2; Sun, 17 Mar 2013 15:59:36 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 0C4DE81E; Sun, 17 Mar 2013 15:59:35 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r2HFxW7a081777; Sun, 17 Mar 2013 17:59:32 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.0 kib.kiev.ua r2HFxW7a081777 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r2HFxW8U081776; Sun, 17 Mar 2013 17:59:32 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 17 Mar 2013 17:59:32 +0200 From: Konstantin Belousov To: Pawel Jakub Dawidek Subject: Re: chflagsat(2). Message-ID: <20130317155932.GS3794@kib.kiev.ua> References: <20130317004908.GB1364@garage.freebsd.pl> <20130317064338.GN3794@kib.kiev.ua> <20130317111931.GD1364@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XDVLi0tRPfHfrgwa" Content-Disposition: inline In-Reply-To: <20130317111931.GD1364@garage.freebsd.pl> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Mar 2013 15:59:36 -0000 --XDVLi0tRPfHfrgwa Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Mar 17, 2013 at 12:19:31PM +0100, Pawel Jakub Dawidek wrote: > On Sun, Mar 17, 2013 at 08:43:38AM +0200, Konstantin Belousov wrote: > > On Sun, Mar 17, 2013 at 01:49:08AM +0100, Pawel Jakub Dawidek wrote: > > > Hi. > > >=20 > > > The following patch adds chflagsat(2) syscall to complete other *at > > > syscalls: > > >=20 > > > http://people.freebsd.org/~pjd/patches/chflagsat.patch > > >=20 > > > Note that the name chflagsat was carefully choosen instead of > > > fchflagsat, to not repeat POSIX (more likely Linux) mistakes of using > > > fchmodat, fchownat, futimesat, etc. names when they really shouldn't > > > start with an 'f'. > >=20 > > This is the only point I do not agree with the patch. I prefer to have > > the syscall name consistent with the other syscalls. >=20 > There are quite a few *at() syscalls and only few of them have bogus 'f' > prefix (fchmodat, fchownat, fstatat, futimesat). Most of them don't > (bindat, connectat, linkat, mkdirat, mkfifoat, mknodat, openat, > renameat, symlinkat, unlinkat). 'f' is of course bogus, because the > syscalls don't operate on descriptors, but on paths. chflagsat(2) is similar to fchmodat(2) and fchownat(2), this is why I noted about consistency. > Also note that POSIX is moving aways from those mistakes and eventhough > they standarized futimesat(), they now use utimensat() for nanosecond > precision timestamps to stop those mistakes. This is actually the > argument jilles' convinced me to use chflagsat instead of fchflagsat, > which is originally used. Ok. --XDVLi0tRPfHfrgwa Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRRehjAAoJEJDCuSvBvK1BPJAP/2le60fPDO5kP1YdN+sZ+BR6 A8xCtPClAmKhS7Hxs1+1B+BLpdlkzaY7cbfqijndrEGCv0Nco/OJRJG25vurfxOt 0YKucm2k0sNW1sCF21bydlsxbrieZZg/KfZV48t2d8neLeeYj8DL84Llvo+usaW6 h3CJIjwiz/kQUgKKEWjUfK+6w1YY87QuYsu4mFA6me1zwyNj2Y4vNNyt8bRDQsMf YmVoxO6DLKfU5fCUeaveDEPmFeA8e1R4b2t8IKWy/btoeU6sFeA9fMjbyOY1SHRn 1+e/tA2WvD3wlb2TU9XGMYWAyj9KgEiqjQ87jrVF4hpyEFbVWoqQWhyFwE74PjtL 3NqQoN4vE5D/pa0yqymXJfYfp/dSqhvb02kQGW8okenQTGixEmTqCxpn/NhoAC+O YIPXCVSOa/WS6pmz17hFBJHyGwGRl3ZnO11icw1I7npzgYmSSD38RqDN9+N1RqmA Eysgt2tUZA4IvEBRJI7w8hB1Owvy7ncGTiWIfIKLomVPFYZB5wKa1o6aZSTGbel2 VgUWUnlR7u9I3Suqeoz/Hdp9emQwqKb+eyymeNruaAN0MXP8Qwh/DIbllh2yQNUC /TX+WeJ68N72gKYe4hCJUZb1yOeDAXR23AARIXulyq1h9bLSNrvWEOddOec1kn03 kKCpaAZArs2EtzNfjaKW =D15Y -----END PGP SIGNATURE----- --XDVLi0tRPfHfrgwa-- From owner-freebsd-arch@FreeBSD.ORG Sun Mar 17 16:18:51 2013 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 734B05CA for ; Sun, 17 Mar 2013 16:18:51 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (garage.dawidek.net [91.121.88.72]) by mx1.freebsd.org (Postfix) with ESMTP id 3C6918A2 for ; Sun, 17 Mar 2013 16:18:50 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id EE01D257; Sun, 17 Mar 2013 17:15:33 +0100 (CET) Date: Sun, 17 Mar 2013 17:20:22 +0100 From: Pawel Jakub Dawidek To: Konstantin Belousov Subject: Re: chflags(2)'s flags argument. Message-ID: <20130317162021.GG1364@garage.freebsd.pl> References: <20130317003559.GA1364@garage.freebsd.pl> <20130317064123.GM3794@kib.kiev.ua> <20130317111112.GC1364@garage.freebsd.pl> <20130317155743.GR3794@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yZnyZsPjQYjG7xG7" Content-Disposition: inline In-Reply-To: <20130317155743.GR3794@kib.kiev.ua> X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Mar 2013 16:18:51 -0000 --yZnyZsPjQYjG7xG7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Mar 17, 2013 at 05:57:43PM +0200, Konstantin Belousov wrote: > On Sun, Mar 17, 2013 at 12:11:12PM +0100, Pawel Jakub Dawidek wrote: > > On Sun, Mar 17, 2013 at 08:41:23AM +0200, Konstantin Belousov wrote: > > > The patch seems to keep ABI intact for all useful purposes, at least > > > on all architectures the FreeBSD supports. A FreeBSD architecture whe= re > > > sizeof(int) !=3D sizeof(long), uses register calling conventions. > >=20 > > Actually I'd rephrase that. If I understand correctly, because we use > > register calling conventions on architectures where sizeof(int) !=3D > > sizeof(long), this mess is working correctly now. Remember that syscalls > > are defined to take int, but prototypes say unsigned long. > It needs some untangling. >=20 > The ABI exported by libc is what I care about when referring to the ABI. > And this is the ABI which is not broken due to the reason I stated above. Right, but what I was trying to say is that if we had architecture where sizeof(int) !=3D sizeof(long) and where we don't use register calling conventions chflags(2) and fchflags(2) will never work in the first place. So one might say it is a lucky coincidence. Am I correct? Without committing my patch if we ever add such an architecture chflags(2) and fchflags(2) will not work there properly (maybe depending also on the byte order). > > I know it can break API in some rare cases like in chflags(1), but it > > results in compilation error (at least with the compilation flags we > > use), so can be easly spotted and fixed, hopefully: > >=20 > > /usr/home/pjd/p4/capkern/bin/chflags/chflags.c: In function 'main': > > /usr/home/pjd/p4/capkern/bin/chflags/chflags.c:120: warning: assignment= from incompatible pointer type > >=20 >=20 > Project aims to maintain better compatibility then to claim that > the changes could be 'spotted'. Should I read this as you being against the proposed change? --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --yZnyZsPjQYjG7xG7 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlFF7UUACgkQForvXbEpPzQEaQCbBg4qQaP7jO+C5tmlbMvdUfoO r1AAoMK4gXZLgFrotZJbZkueiRh/R5ZF =ia0+ -----END PGP SIGNATURE----- --yZnyZsPjQYjG7xG7-- From owner-freebsd-arch@FreeBSD.ORG Sun Mar 17 16:25:38 2013 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6784D7ED; Sun, 17 Mar 2013 16:25:38 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id D3AD88D7; Sun, 17 Mar 2013 16:25:37 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r2HGPY9e087069; Sun, 17 Mar 2013 18:25:34 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.0 kib.kiev.ua r2HGPY9e087069 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r2HGPXQF087068; Sun, 17 Mar 2013 18:25:33 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 17 Mar 2013 18:25:33 +0200 From: Konstantin Belousov To: Pawel Jakub Dawidek Subject: Re: chflags(2)'s flags argument. Message-ID: <20130317162533.GT3794@kib.kiev.ua> References: <20130317003559.GA1364@garage.freebsd.pl> <20130317064123.GM3794@kib.kiev.ua> <20130317111112.GC1364@garage.freebsd.pl> <20130317155743.GR3794@kib.kiev.ua> <20130317162021.GG1364@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="X+WXP0omYNJFGow2" Content-Disposition: inline In-Reply-To: <20130317162021.GG1364@garage.freebsd.pl> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Mar 2013 16:25:38 -0000 --X+WXP0omYNJFGow2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Mar 17, 2013 at 05:20:22PM +0100, Pawel Jakub Dawidek wrote: > On Sun, Mar 17, 2013 at 05:57:43PM +0200, Konstantin Belousov wrote: > > On Sun, Mar 17, 2013 at 12:11:12PM +0100, Pawel Jakub Dawidek wrote: > > > On Sun, Mar 17, 2013 at 08:41:23AM +0200, Konstantin Belousov wrote: > > > > The patch seems to keep ABI intact for all useful purposes, at least > > > > on all architectures the FreeBSD supports. A FreeBSD architecture w= here > > > > sizeof(int) !=3D sizeof(long), uses register calling conventions. > > >=20 > > > Actually I'd rephrase that. If I understand correctly, because we use > > > register calling conventions on architectures where sizeof(int) !=3D > > > sizeof(long), this mess is working correctly now. Remember that sysca= lls > > > are defined to take int, but prototypes say unsigned long. > > It needs some untangling. > >=20 > > The ABI exported by libc is what I care about when referring to the ABI. > > And this is the ABI which is not broken due to the reason I stated abov= e. >=20 > Right, but what I was trying to say is that if we had architecture where > sizeof(int) !=3D sizeof(long) and where we don't use register calling > conventions chflags(2) and fchflags(2) will never work in the first > place. So one might say it is a lucky coincidence. >=20 > Am I correct? Without committing my patch if we ever add such an > architecture chflags(2) and fchflags(2) will not work there properly > (maybe depending also on the byte order). Yes, you are right. >=20 > > > I know it can break API in some rare cases like in chflags(1), but it > > > results in compilation error (at least with the compilation flags we > > > use), so can be easly spotted and fixed, hopefully: > > >=20 > > > /usr/home/pjd/p4/capkern/bin/chflags/chflags.c: In function 'main': > > > /usr/home/pjd/p4/capkern/bin/chflags/chflags.c:120: warning: assignme= nt from incompatible pointer type > > >=20 > >=20 > > Project aims to maintain better compatibility then to claim that > > the changes could be 'spotted'. >=20 > Should I read this as you being against the proposed change? No, I do not object. But, did you considered changing the syscall argument to unsigned long instead ? --X+WXP0omYNJFGow2 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRRe59AAoJEJDCuSvBvK1BTDkP/1kMSCsnLlV1aT0hFTMk3/7+ czxaFEqaEtVTL3G3vZUrPEGFOwNjDsRVYAl5iq7u+mC4qvSvkigL4d/ZScZ4RNRr /dqnFn0VGqTyUSRsVrqncAT3kkI4CBEbyFocxIdmCi25Qg7EDHMIpItshgVFb37n 8WKRLw0uNeUJ9ZXCcvilOK5pcO1swBwUxSmPbm+G7+olBqgNT8l4zSbuAO0BB/vB wdVGJKpKQ+IhGcCJz+WiN03qW6YbZBRGJzEW6NT2LHrl3RlY0zemxf/YcciFLIrq IJhYwwnXmpH59FpQY40CUruznGx//aqSQtxoyEBZrufYuaxmDmqM6EfwiT5oMEhA 8UVigdXrgbSxigKSfjmu8gcB1ayKWO0frymkaiuSp4WsrXgqz9TdUYYxgPOjZOO6 PLr7lOIKQHV7TEfQ1cLcbr7FIeGscSkPBFsJJi+zaNcokITqOkQEWoN/UdrliIWB X6f+RjDwrtfZhGBajJtGAU+9cPPRZkzPka5fME/340ivaNwlnDv5SySvKYPaBMLm rvANRWZ4xCsZfLPFrvwjetsoaA9vIdKGeMfakKnp+dvw0L1vOM6zHfurYhL4BIpu U2HqYaoz1yaMIvOpmLgzQ5l5VwBc65CsLI1UCRvV7iukYN4R20xeAlnRhGBjiiPK jaM+cIwdlqG7J4xVcW6I =s7ez -----END PGP SIGNATURE----- --X+WXP0omYNJFGow2-- From owner-freebsd-arch@FreeBSD.ORG Sun Mar 17 16:45:01 2013 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B6B92BF for ; Sun, 17 Mar 2013 16:45:01 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (garage.dawidek.net [91.121.88.72]) by mx1.freebsd.org (Postfix) with ESMTP id 80FE197F for ; Sun, 17 Mar 2013 16:45:00 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id CCF5F267; Sun, 17 Mar 2013 17:41:44 +0100 (CET) Date: Sun, 17 Mar 2013 17:46:33 +0100 From: Pawel Jakub Dawidek To: Konstantin Belousov Subject: Re: chflags(2)'s flags argument. Message-ID: <20130317164632.GI1364@garage.freebsd.pl> References: <20130317003559.GA1364@garage.freebsd.pl> <20130317064123.GM3794@kib.kiev.ua> <20130317111112.GC1364@garage.freebsd.pl> <20130317155743.GR3794@kib.kiev.ua> <20130317162021.GG1364@garage.freebsd.pl> <20130317162533.GT3794@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ev7mvGV+3JQuI2Eo" Content-Disposition: inline In-Reply-To: <20130317162533.GT3794@kib.kiev.ua> X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Mar 2013 16:45:01 -0000 --ev7mvGV+3JQuI2Eo Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Mar 17, 2013 at 06:25:33PM +0200, Konstantin Belousov wrote: > On Sun, Mar 17, 2013 at 05:20:22PM +0100, Pawel Jakub Dawidek wrote: > > On Sun, Mar 17, 2013 at 05:57:43PM +0200, Konstantin Belousov wrote: > > > On Sun, Mar 17, 2013 at 12:11:12PM +0100, Pawel Jakub Dawidek wrote: > > > > I know it can break API in some rare cases like in chflags(1), but = it > > > > results in compilation error (at least with the compilation flags we > > > > use), so can be easly spotted and fixed, hopefully: > > > >=20 > > > > /usr/home/pjd/p4/capkern/bin/chflags/chflags.c: In function 'main': > > > > /usr/home/pjd/p4/capkern/bin/chflags/chflags.c:120: warning: assign= ment from incompatible pointer type > > > >=20 > > >=20 > > > Project aims to maintain better compatibility then to claim that > > > the changes could be 'spotted'. > >=20 > > Should I read this as you being against the proposed change? >=20 > No, I do not object. But, did you considered changing the syscall argument > to unsigned long instead ? Well, the main reason behind this change is to make all chflags(2) syscalls consistent. I didn't consider changing syscall argument to unsigned long, but then I'd need to update lchflags(2) to take unsigned long to make it consistent with others, which has the exact same implications. Now that I think about this, changing lchflags(2) argument to unsigned long might be better option, because: - It would make all those syscalls consistent with strtofflags(3) and fflagstostr(3). - It would decrease the risk of possible breakage, as lchflags(2) is rarely used. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --ev7mvGV+3JQuI2Eo Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlFF82gACgkQForvXbEpPzRvxwCfXDczTJTta1E81k0//4aONOyq CNcAoM+o5+jscnGRgejEWfzmLbTjxU2z =X6V/ -----END PGP SIGNATURE----- --ev7mvGV+3JQuI2Eo-- From owner-freebsd-arch@FreeBSD.ORG Sun Mar 17 17:42:10 2013 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3845C257; Sun, 17 Mar 2013 17:42:10 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 7B14EAF4; Sun, 17 Mar 2013 17:42:09 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r2HHg5BX000402; Sun, 17 Mar 2013 19:42:05 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.0 kib.kiev.ua r2HHg5BX000402 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r2HHg5rZ000401; Sun, 17 Mar 2013 19:42:05 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 17 Mar 2013 19:42:05 +0200 From: Konstantin Belousov To: Pawel Jakub Dawidek Subject: Re: chflags(2)'s flags argument. Message-ID: <20130317174205.GU3794@kib.kiev.ua> References: <20130317003559.GA1364@garage.freebsd.pl> <20130317064123.GM3794@kib.kiev.ua> <20130317111112.GC1364@garage.freebsd.pl> <20130317155743.GR3794@kib.kiev.ua> <20130317162021.GG1364@garage.freebsd.pl> <20130317162533.GT3794@kib.kiev.ua> <20130317164632.GI1364@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ncfrQ09dBbS73TfA" Content-Disposition: inline In-Reply-To: <20130317164632.GI1364@garage.freebsd.pl> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Mar 2013 17:42:10 -0000 --ncfrQ09dBbS73TfA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Mar 17, 2013 at 05:46:33PM +0100, Pawel Jakub Dawidek wrote: > On Sun, Mar 17, 2013 at 06:25:33PM +0200, Konstantin Belousov wrote: > > On Sun, Mar 17, 2013 at 05:20:22PM +0100, Pawel Jakub Dawidek wrote: > > > On Sun, Mar 17, 2013 at 05:57:43PM +0200, Konstantin Belousov wrote: > > > > On Sun, Mar 17, 2013 at 12:11:12PM +0100, Pawel Jakub Dawidek wrote: > > > > > I know it can break API in some rare cases like in chflags(1), bu= t it > > > > > results in compilation error (at least with the compilation flags= we > > > > > use), so can be easly spotted and fixed, hopefully: > > > > >=20 > > > > > /usr/home/pjd/p4/capkern/bin/chflags/chflags.c: In function 'main= ': > > > > > /usr/home/pjd/p4/capkern/bin/chflags/chflags.c:120: warning: assi= gnment from incompatible pointer type > > > > >=20 > > > >=20 > > > > Project aims to maintain better compatibility then to claim that > > > > the changes could be 'spotted'. > > >=20 > > > Should I read this as you being against the proposed change? > >=20 > > No, I do not object. But, did you considered changing the syscall argum= ent > > to unsigned long instead ? >=20 > Well, the main reason behind this change is to make all chflags(2) > syscalls consistent. I didn't consider changing syscall argument to > unsigned long, but then I'd need to update lchflags(2) to take unsigned > long to make it consistent with others, which has the exact same > implications. >=20 > Now that I think about this, changing lchflags(2) argument to unsigned > long might be better option, because: >=20 > - It would make all those syscalls consistent with strtofflags(3) and > fflagstostr(3). >=20 > - It would decrease the risk of possible breakage, as lchflags(2) is > rarely used. I would say that API and ABI stability is more important then the consistency. I think we are in the agreement of changing the kernel interface for the chflags/fchflags to use long for flags. For lchflags, my opinion is that the best would be not to change it. --ncfrQ09dBbS73TfA Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRRgBsAAoJEJDCuSvBvK1B1YMP/RCjbJa4OhkG07QbyRAYwMS2 qeR0AcdhBkQwOVj+/GcJiLLKrQ2sS1jcpT4UTeLpGGpc4kzMSBI2zdbL7p2Qm6sH 4+6tcCf3CUhIqtXvl6d75lbh579cn1uHKDTzYCLNQf92rzK03RKmzCX2YObN7rp7 sEjsQiG9BvuFW0c+xDXVPqZX5eVlXj0r/Tk6kqINH9+Dh182vzS/Xib0Z16iVBAc 677y3ak8m0SnuTzYYMP1BtzuiCNVYIDCmZVeIE2tLWE9LvvUbjpYUagccJaZ88u5 LN5wehLRyE2XCQHLQn5sy2HI9yAWuKJP1Zi26xMLwFJswRYRQOU4vpl6sFC5KjiG wZ1eS2dMXt/YuyNMgja706no33AUi1pZMCBLiWTDmdmOh3EMuEjLCohPm6ZTYdBJ oUtjDGsEcXPx6smrbZIicytMg+Zqjce8kJ8mUJWQ1j/YT9CJxV+iub7bsfP/M8Vp cSRemgXfQqEaUXgxmAvSGeV4ufv69XjfjPMHec7zYpFC3wJSVPbGA+5+aBYjdZJf XOTJS/4vn8qWNHuynlN/aIYI4FnsgRsRv4JEV9bzr7FV2pXiHBSQs40MoQ6rfS66 GYdzCBtwU0dGmdPmS7e+/1Zuvkp+dlSmB0bwXHdg0APz/kKQYAXCuSB/3qeLOqPt EzvdrrFBhKDYU7hL7WpG =bFny -----END PGP SIGNATURE----- --ncfrQ09dBbS73TfA-- From owner-freebsd-arch@FreeBSD.ORG Sun Mar 17 18:14:22 2013 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3744BA41; Sun, 17 Mar 2013 18:14:22 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (unknown [IPv6:2001:610:1108:5012::107]) by mx1.freebsd.org (Postfix) with ESMTP id F40ECC21; Sun, 17 Mar 2013 18:14:21 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id D158B1203B1; Sun, 17 Mar 2013 19:14:05 +0100 (CET) Received: by snail.stack.nl (Postfix, from userid 1677) id AB2592848C; Sun, 17 Mar 2013 19:14:05 +0100 (CET) Date: Sun, 17 Mar 2013 19:14:05 +0100 From: Jilles Tjoelker To: Pawel Jakub Dawidek Subject: Re: chflagsat(2). Message-ID: <20130317181405.GB65525@stack.nl> References: <20130317004908.GB1364@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130317004908.GB1364@garage.freebsd.pl> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Mar 2013 18:14:22 -0000 On Sun, Mar 17, 2013 at 01:49:08AM +0100, Pawel Jakub Dawidek wrote: > The following patch adds chflagsat(2) syscall to complete other *at > syscalls: > http://people.freebsd.org/~pjd/patches/chflagsat.patch > Note that the name chflagsat was carefully choosen instead of > fchflagsat, to not repeat POSIX (more likely Linux) mistakes of using > fchmodat, fchownat, futimesat, etc. names when they really shouldn't > start with an 'f'. Looks good to me. My manual page text is actually in this patch, not in the other one you sent on the same day. -- Jilles Tjoelker From owner-freebsd-arch@FreeBSD.ORG Sun Mar 17 20:01:22 2013 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C105F730; Sun, 17 Mar 2013 20:01:22 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) by mx1.freebsd.org (Postfix) with ESMTP id 89925FBE; Sun, 17 Mar 2013 20:01:22 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id DD0923592E5; Sun, 17 Mar 2013 21:01:21 +0100 (CET) Received: by snail.stack.nl (Postfix, from userid 1677) id B360F2848C; Sun, 17 Mar 2013 21:01:21 +0100 (CET) Date: Sun, 17 Mar 2013 21:01:21 +0100 From: Jilles Tjoelker To: Pawel Jakub Dawidek Subject: Re: chflags(2)'s flags argument. Message-ID: <20130317200121.GC65525@stack.nl> References: <20130317003559.GA1364@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130317003559.GA1364@garage.freebsd.pl> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Mar 2013 20:01:22 -0000 On Sun, Mar 17, 2013 at 01:35:59AM +0100, Pawel Jakub Dawidek wrote: > Currently this is a bit messy: chflags(2) and fchflags(2) take 'flags' > argument of type unsigned long and lchflags(2) takes the same argument > of type int. At least this is what you can see in manual page and in > prototypes of those functions in sys/stat.h. > However all of those syscalls are defined in syscalls.master to take the > 'flags' argument of type int and this is what they use in kernel. > I'd like to proposed the following patch: > http://people.freebsd.org/~pjd/patches/chflags_int.patch > It changes type of the 'flags' argument from unsigned long to int where > possible. > I believe this change won't break ABI, as the syscalls (apart from the > prototypes) already expect int and I hope in doesn't break API in any > really visible and destructive way. If you think otherwise, let me know. I wonder if we want to keep all those ugly casts between the various types for file flags. They are unnecessary and might get stale. For example, if (fchflags(to_fd, (u_long)sbp->st_flags)) (or changed to (int)). The cast may have been necessary in the bad old days without prototypes. > Note that the patch doesn't touch the strtofflags(3) function, as I > believe it would break ABI and it doesn't touch the fflagstostr(3) > function to stay consistent with strtofflags(3). That's int and unsigned long. That's not the complete collection. The st_flags member of struct stat is of type fflags_t which is a typedef for uint32_t. It is sad what a mess this is :( > PS. Manual page text provided by jilles. The manual page text is, in fact, in the chflagsat(2) patch. -- Jilles Tjoelker From owner-freebsd-arch@FreeBSD.ORG Sun Mar 17 21:08:58 2013 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0DAD84D9 for ; Sun, 17 Mar 2013 21:08:58 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (garage.dawidek.net [91.121.88.72]) by mx1.freebsd.org (Postfix) with ESMTP id BD1C228A for ; Sun, 17 Mar 2013 21:08:57 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id A28462EA; Sun, 17 Mar 2013 22:05:40 +0100 (CET) Date: Sun, 17 Mar 2013 22:10:28 +0100 From: Pawel Jakub Dawidek To: Konstantin Belousov Subject: Re: chflags(2)'s flags argument. Message-ID: <20130317211027.GJ1364@garage.freebsd.pl> References: <20130317003559.GA1364@garage.freebsd.pl> <20130317064123.GM3794@kib.kiev.ua> <20130317111112.GC1364@garage.freebsd.pl> <20130317155743.GR3794@kib.kiev.ua> <20130317162021.GG1364@garage.freebsd.pl> <20130317162533.GT3794@kib.kiev.ua> <20130317164632.GI1364@garage.freebsd.pl> <20130317174205.GU3794@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZG+WKzXzVby2T9Ro" Content-Disposition: inline In-Reply-To: <20130317174205.GU3794@kib.kiev.ua> X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Mar 2013 21:08:58 -0000 --ZG+WKzXzVby2T9Ro Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Mar 17, 2013 at 07:42:05PM +0200, Konstantin Belousov wrote: > I would say that API and ABI stability is more important then the > consistency. I think we are in the agreement of changing the kernel > interface for the chflags/fchflags to use long for flags. >=20 > For lchflags, my opinion is that the best would be not to change it. ABI is out of question, we do preserve its stability. And as for API, I think it is really low price to pay (if any) for consistency and would also allow us to get rid of hacks like the one in chflags(1): int (*change_flags)(const char *, unsigned long); [...] /* XXX: Why don't chflags and lchflags have compatible prototypes? */ if (hflag) change_flags =3D (int (*)(const char *, unsigned long))lchflags; else change_flags =3D chflags; In common case when program just calls lchflags() directly it won't even notice API change. Maybe we could arrange ports build with lchflags(2) changed to take unsigned long to see how destructive the change really is, because my expectation is that not very. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --ZG+WKzXzVby2T9Ro Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlFGMUMACgkQForvXbEpPzRUXwCfZu3S0jvikBRJ9Yg2S9ycwyye 5fAAoPeyCDkj7M0gqozGvEZ6otN2lsCY =J9a3 -----END PGP SIGNATURE----- --ZG+WKzXzVby2T9Ro-- From owner-freebsd-arch@FreeBSD.ORG Mon Mar 18 05:57:05 2013 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id DBAA0285; Mon, 18 Mar 2013 05:57:05 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from fallbackmx07.syd.optusnet.com.au (fallbackmx07.syd.optusnet.com.au [211.29.132.9]) by mx1.freebsd.org (Postfix) with ESMTP id 4AEC0750; Mon, 18 Mar 2013 05:57:04 +0000 (UTC) Received: from mail17.syd.optusnet.com.au (mail17.syd.optusnet.com.au [211.29.132.198]) by fallbackmx07.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id r2I5pXim007710; Mon, 18 Mar 2013 16:51:34 +1100 Received: from c211-30-173-106.carlnfd1.nsw.optusnet.com.au (c211-30-173-106.carlnfd1.nsw.optusnet.com.au [211.30.173.106]) by mail17.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id r2I5pMFl002373 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 Mar 2013 16:51:24 +1100 Date: Mon, 18 Mar 2013 16:51:22 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Pawel Jakub Dawidek Subject: Re: chflags(2)'s flags argument. In-Reply-To: <20130317211027.GJ1364@garage.freebsd.pl> Message-ID: <20130318155059.V925@besplex.bde.org> References: <20130317003559.GA1364@garage.freebsd.pl> <20130317064123.GM3794@kib.kiev.ua> <20130317111112.GC1364@garage.freebsd.pl> <20130317155743.GR3794@kib.kiev.ua> <20130317162021.GG1364@garage.freebsd.pl> <20130317162533.GT3794@kib.kiev.ua> <20130317164632.GI1364@garage.freebsd.pl> <20130317174205.GU3794@kib.kiev.ua> <20130317211027.GJ1364@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.0 cv=W/lgzmqk c=1 sm=1 a=mueDxCsUSoQA:10 a=kj9zAlcOel0A:10 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=IpFD8tbXDcUA:10 a=DE-IkRQ1Tq0Gzbl4-6gA:9 a=CjuIK1q_8ugA:10 a=LXPfRs8EBeKUz12H:21 a=h0ZvHKAk39ts7DFE:21 a=TEtd8y5WR3g2ypngnwZWYw==:117 Cc: Konstantin Belousov , freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 05:57:05 -0000 On Sun, 17 Mar 2013, Pawel Jakub Dawidek wrote: > On Sun, Mar 17, 2013 at 07:42:05PM +0200, Konstantin Belousov wrote: >> I would say that API and ABI stability is more important then the >> consistency. I think we are in the agreement of changing the kernel >> interface for the chflags/fchflags to use long for flags. >> >> For lchflags, my opinion is that the best would be not to change it. > > ABI is out of question, we do preserve its stability. And as for API, > I think it is really low price to pay (if any) for consistency and would > also allow us to get rid of hacks like the one in chflags(1): I think it is possible to just change it. The correct API is of course that the function arg type is the default promotion of the type of st_flags. Fortunately this is the same (u_int) on all supported arches. > > int (*change_flags)(const char *, unsigned long); > [...] > /* XXX: Why don't chflags and lchflags have compatible prototypes? */ > if (hflag) > change_flags = (int (*)(const char *, unsigned long))lchflags; > else > change_flags = chflags; Why do people write garbage like that? This hack is not necessary. It just uses bogus casts to break the warning about undefined behaviour when the pointer is used. The cast is valid, but the function pointer created by it is only usable if it is converted back to the type of the original function. That is not done, so the result is undefined. (This result is whatever happens when the lchflags() function is passed a u_long arg instead of the int arg that it expects. The kernel uses similar type puns with more reason, and works less accidentally.) Fixing this to use the pointer correctly takes slightly more code than just using the unpointed-to functions directly, not counting the 6 times as much code needed for the garbage: @ diff -u2 chflags.c~ chflags.c @ --- chflags.c~ 2010-12-26 17:19:39.000000000 +0000 @ +++ chflags.c 2013-03-18 04:43:45.515645000 +0000 @ @@ -66,5 +66,4 @@ @ int ch, fts_options, oct, rval; @ char *flags, *ep; @ - int (*change_flags)(const char *, unsigned long); @ @ Hflag = Lflag = Rflag = fflag = hflag = vflag = 0; @ @@ -118,10 +117,4 @@ @ fts_options = hflag ? FTS_PHYSICAL : FTS_LOGICAL; @ @ - /* XXX: Why don't chflags and lchflags have compatible prototypes? */ @ - if (hflag) @ - change_flags = (int (*)(const char *, unsigned long))lchflags; @ - else @ - change_flags = chflags; @ - @ flags = *argv; @ if (*flags >= '0' && *flags <= '7') { @ @@ -180,5 +173,6 @@ @ if (newflags == p->fts_statp->st_flags) @ continue; @ - if ((*change_flags)(p->fts_accpath, newflags) && !fflag) { @ + if ((hflag ? lchflags(p->fts_accpath, newflags) : @ + chflags(p->fts_accpath, newflags)) & !fflag) { @ warn("%s", p->fts_path); @ rval = 1; cp/utils.c already uses correct code. It uses a 3-way selection between fchflags, lchflags and chflags, and fchflags is too obviously different to be corruptible using a pointer as above. (The 3-way selection is bogus, however. The chflags case in it is unreachable, at least with other changes, since the case of a non-link is or should always be handled using a file descriptor. Using a file descriptor reduces races but is unfortunately impossible for symlinks.) > In common case when program just calls lchflags() directly it won't even > notice API change. And in the uncommon case, broken code like the above won't even notice that the API change unbreaks it, since the brokenness must have been being for the broken code to appear to work. Except the unbreakage would prevent the compiler reporting the above as garbage. (The lifetime analysis for the pointer is simple, so it is fairly easy to see that it is always garbage when it is used with hflag != 0. The compiler could, instead of reporting this, validly optimize away that case.) > Maybe we could arrange ports build with lchflags(2) changed to take > unsigned long to see how destructive the change really is, because my > expectation is that not very. Why not use the correct type (u_int)? u_long is just too long, since st_flags is only 32 bits, so much larger and realler API and ABI changes would be needed to support more than 32 flags. The original poorly chosen u_long types are probably due to 4.4BSD having vestiges of support for 16-bit ints. Old BSDs used long for almost everthing that might be large. For example, pid_t was long in 4.4BSD-Lite1. This mainly caused ABI problems on 64-bit arches, so NetBSD changed most of these longs to int32_t. 4.4BSD-Lite1 picked up many of these changes, and FreeBSD got them from Lite2. But NetBSD didn't change the u_longs in [f]chflags(). FreeBSD enlarged the mess by importing lchflags() from NetBSD and changing its arg type to int. The garbage also has some style bugs. It spells "unsigned long" as itself. All other code in chflags.c still uses the normal abbreviation u_long. Now I remember where the hack came from. It is not from cp/utils.c, but from copying similar pointer code in chmod/chmod.c and chown/chown.c There using the pointer is just verbose minor obfuscation. My version cleans up chmod as follows: @ diff -u2 chmod.c~ chmod.c @ --- chmod.c~ Wed Apr 7 20:21:29 2004 @ +++ chmod.c Wed Apr 7 20:21:30 2004 @ @@ -66,5 +65,4 @@ @ char *mode; @ mode_t newmode; @ - int (*change_mode)(const char *, mode_t); @ @ set = NULL; @ @@ -140,9 +145,4 @@ @ fts_options = hflag ? FTS_PHYSICAL : FTS_LOGICAL; @ @ - if (hflag) @ - change_mode = lchmod; @ - else @ - change_mode = chmod; @ - @ mode = *argv; @ if ((set = setmode(mode)) == NULL) @ @@ -183,11 +182,12 @@ @ if ((newmode & ALLPERMS) == (p->fts_statp->st_mode & ALLPERMS)) @ continue; @ - if ((*change_mode)(p->fts_accpath, newmode) && !fflag) { @ - warn("%s", p->fts_path); @ - rval = 1; @ + if ((hflag ? lchmod : chmod)(p->fts_accpath, newmode)) { @ + if (!fflag) { @ + warn("%s", p->fts_path); @ + rval = 1; @ + } @ } else { @ if (vflag) { @ (void)printf("%s", p->fts_path); @ - @ if (vflag > 1) { @ char m1[12], m2[12]; -current does this differently. It has the same fflag fix. It doesn't have the vflag cleanup. It uses different verboseness for the hflag part: if (hflag) error = lchmod(p->fts_accpath, newmode); else error = chmod(p->fts_accpath, newmode); if (error) ... lchflags()'s different prototype prevents using the conditional operator cleanly, but using it is still better (2 lines instead of 5, with clearer logic). chown/chown.c in -current does all this cleanly. Only its nearby printing for vflag is ugly. Bruce From owner-freebsd-arch@FreeBSD.ORG Mon Mar 18 21:06:46 2013 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8227BB63 for ; Mon, 18 Mar 2013 21:06:46 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (garage.dawidek.net [91.121.88.72]) by mx1.freebsd.org (Postfix) with ESMTP id 3AC98AC4 for ; Mon, 18 Mar 2013 21:06:45 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id E446D707; Mon, 18 Mar 2013 22:03:22 +0100 (CET) Date: Mon, 18 Mar 2013 22:08:17 +0100 From: Pawel Jakub Dawidek To: Bruce Evans Subject: Re: chflags(2)'s flags argument. Message-ID: <20130318210817.GA1367@garage.freebsd.pl> References: <20130317003559.GA1364@garage.freebsd.pl> <20130317064123.GM3794@kib.kiev.ua> <20130317111112.GC1364@garage.freebsd.pl> <20130317155743.GR3794@kib.kiev.ua> <20130317162021.GG1364@garage.freebsd.pl> <20130317162533.GT3794@kib.kiev.ua> <20130317164632.GI1364@garage.freebsd.pl> <20130317174205.GU3794@kib.kiev.ua> <20130317211027.GJ1364@garage.freebsd.pl> <20130318155059.V925@besplex.bde.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZGiS0Q5IWpPtfppv" Content-Disposition: inline In-Reply-To: <20130318155059.V925@besplex.bde.org> X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Konstantin Belousov , freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 21:06:46 -0000 --ZGiS0Q5IWpPtfppv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Mar 18, 2013 at 04:51:22PM +1100, Bruce Evans wrote: > On Sun, 17 Mar 2013, Pawel Jakub Dawidek wrote: > > Maybe we could arrange ports build with lchflags(2) changed to take > > unsigned long to see how destructive the change really is, because my > > expectation is that not very. >=20 > Why not use the correct type (u_int)? u_long is just too long, since > st_flags is only 32 bits, so much larger and realler API and ABI changes > would be needed to support more than 32 flags. I'd prefer leave u_long, as it breaks API as little as possible. This is also the type that's being used by consumers of this API, as it was documented in chflags(2) since forever. Also, as I already mentioned, strtofflags(3) and fflagstostr(3) uses this type too. > The garbage also has some style bugs. It spells "unsigned long" as > itself. All other code in chflags.c still uses the normal abbreviation > u_long. Using u_long for chflags() prototypes in sys/stat.h will only work, because of this: #if !defined(_KERNEL) && __BSD_VISIBLE /* * XXX We get miscellaneous namespace pollution with this. */ #include #endif As sys/time.h will include sys/types.h, eventhough sys/stat.h is trying to avoid that at the begining. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --ZGiS0Q5IWpPtfppv Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlFHgkEACgkQForvXbEpPzQdUACeL0zb1OyES3PV70QqYXRwykGM kCYAoOvxRT7OhNWLP3lBeQOrALQFZpwd =1m5M -----END PGP SIGNATURE----- --ZGiS0Q5IWpPtfppv-- From owner-freebsd-arch@FreeBSD.ORG Tue Mar 19 20:11:51 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5FA016BF for ; Tue, 19 Mar 2013 20:11:51 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from mail.ambrisko.com (mail.ambrisko.com [70.91.206.90]) by mx1.freebsd.org (Postfix) with ESMTP id 4494D22F for ; Tue, 19 Mar 2013 20:11:51 +0000 (UTC) X-Ambrisko-Me: Yes Received: from server2.ambrisko.com (HELO internal.ambrisko.com) ([192.168.1.2]) by ironport.ambrisko.com with ESMTP; 19 Mar 2013 13:14:19 -0700 Received: from ambrisko.com (localhost [127.0.0.1]) by internal.ambrisko.com (8.14.4/8.14.4) with ESMTP id r2JKBj18033162 for ; Tue, 19 Mar 2013 13:11:45 -0700 (PDT) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.14.4/8.14.4/Submit) id r2JKBjkm033161 for arch@freebsd.org; Tue, 19 Mar 2013 13:11:45 -0700 (PDT) (envelope-from ambrisko) Date: Tue, 19 Mar 2013 13:11:45 -0700 From: Doug Ambrisko To: arch@freebsd.org Subject: Increase the mount path to MAXPATHLEN? Message-ID: <20130319201145.GA19260@ambrisko.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 20:11:51 -0000 At work we use lots of chroots and mount things within those chroots like dev, proc etc. so it looks like a running system. We also do some trickery so that we chroot into different versions of FreeBSD and pull in some of the native binaries so things like mount, ps etc. work inside. We will also create chroots inside that. Since these things live in home directories and mount points can be in various tree's the mount points are getting pretty long. It seems that checking before was weak and let some of these mount worked by accident in prior versions of FreeBSD. Now there is better error checking and the mounts fail since it exceeds MNAMELEN which was 88. I did notice before that sometimes unmount would unmount other things and could be an issues with multiple scripts running at the same time. This doesn't seem to be a problem now. I'd like to bump the mount point to support a larger value then MNAMELEN (88) and to some what avoid this problem in the future thought we should just use MAXPATHLEN. I figure that once start hitting that limit probably a bunch of things are going to pop up. This means we'll need to create new system calls for stat calls and compatibility. It is a pain, since you need to build and install a new kernel before you can run code with the new values. So there is some pain involved. I've made this change locally on a system and has been running for a few months. However, since other people can add system call numbers then conflicts can be a pain to deal with. So if we are going to do something like this then it would be nice to reserve the new number before someone else grabs them. I'd hate to have a bunch of binaries distributed that could cause major issues like this. I noticed STATFS_VERSION defined as: #define STATFS_VERSION 0x20030518 /* current version number */ I'm not sure if we can use that to change the length without changing the system call number. It also might be good if we had a private system call number range so companies could extend them. I recall we had that for major numbers before devfs. I have a patch at: http://people.freebsd.org/~ambrisko/statf.patch that people can glance at. If this approach is the right way to go then I update it for the latest -current and update it. Right now I'm looking at doing this for an internal 9.1 release and would like to grab the system call numbers so I can make that compatible with the future and have future FreeBSD releases support those binaries. I expect as people starting using chroot/jails/vimage as more general purpose on multi-user machines that more people will run into this. This especially happens if the mount points are in home directories etc. I've now started to spin up light weight vimages via doing a nullfs mount of installworld into a machine name, unionfs a backing store to that and then launch a machine via vimage. A simple script can fire up a new machine quickly. Sometimes these "test" machines are just for routing so the diff between them is really small and is captured in the unionfs backing store. Then I can upgrade them via a new installworld to the source nullfs mount and everything gets the new image. To make this easier to support differnt versions of FreeBSD I have some patches so that in a jail you can change the sysctl for kern.osrelease etc. This is easier then trying to get UNAME_* environment variables set for everything. So I find this really useful. Please let me know if there are better methods to do this. Thanks, Doug A. From owner-freebsd-arch@FreeBSD.ORG Wed Mar 20 10:21:28 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 642BF15A; Wed, 20 Mar 2013 10:21:28 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id CEA82CE9; Wed, 20 Mar 2013 10:21:27 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r2KALHxZ054807; Wed, 20 Mar 2013 12:21:17 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.0 kib.kiev.ua r2KALHxZ054807 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r2KALGO1054806; Wed, 20 Mar 2013 12:21:16 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 20 Mar 2013 12:21:16 +0200 From: Konstantin Belousov To: Doug Ambrisko Subject: Re: Increase the mount path to MAXPATHLEN? Message-ID: <20130320102116.GA3794@kib.kiev.ua> References: <20130319201145.GA19260@ambrisko.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FX1XXxwkuRo+XMsw" Content-Disposition: inline In-Reply-To: <20130319201145.GA19260@ambrisko.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: arch@freebsd.org, gleb@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 10:21:28 -0000 --FX1XXxwkuRo+XMsw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Mar 19, 2013 at 01:11:45PM -0700, Doug Ambrisko wrote: > I have a patch at: > http://people.freebsd.org/~ambrisko/statf.patch > that people can glance at. If this approach is the right way to go > then I update it for the latest -current and update it. No, I do not think this is the right approach. You are breaking the ABI in the backward-incompatible way. What should be done is versioning the fstatfs(2) and other related symbols from libc. Please look at the lib/libc/include/compat.h and its use for upgrading the syscalls ABI. Also, the whole ABI of the system should be inspected for the changes, due to possible use of the struct statfs in other structures, or as an argument to other functions. Gleb Kurtsou (gleb@) has a tool which could compare a set of the shlibs before and after change for the ABI drift, using the dward debugging information. I do not remember where it is stored, definitely worth committing somewhere at tools/tools. --FX1XXxwkuRo+XMsw Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRSY2bAAoJEJDCuSvBvK1BM+kP/RZGfV+1z8FHYWx6EJ6Rolt+ EzE6IvsXcJNRVS81rWSCgWfVVfZImosqx66S7b7SdeWA1uJoyFtw4U4j8FUAvJlr /uR5P6xR2+lTcf16VhTZwFTzce8VsxNenmJKTZQJz+xGtE+F3ySRO6fkNAQo38Jn u8iW5+jgId/qrQDoRRnd8ljhAwTKwMC3u7fYzCPnUGnMCa5MKPFaiqrBObtun0GM uU3vene9hWQ3+r3enO2dWYuUbAC6V/KjiEvbpvHx1+aRP0yADIl5N58G08K2Hkse e6ddd2UlT11ydSfPGifZWip4qHUCLcVeH3ZkH4SW6ZEAkPLrqTlxtjOoH1ZOZW4D sNEtmsQXo7Yi6hVwFi/sLIstRJvMevIP1uZU2zgI0/nMBdbKQJOGxIa49vG8/Dic xH8WsYPUkhEp1LLWF+Pwp/BUOpfggcOq1/uccZ7VuSyTnBPpUavhb5orVeW+91Up nZezjijdPH85PADcrapE6hz7of2tN58I/JN/aOxHu2oRdQPx9BsRiUej+InT5fA5 TaHvApBpwa2aADDfmd+5e54r+bF+QyWruY2CkfE6ihr4qk0Ea9RZu4AiNuzvldTw wXQkJ1Gpps/QwmpzC5hxFPyi0UegrKXFFa1J4uiOnm0TQPbRd+1sZpa+I2uGTK8h 4EDsDUiAXr/JJ6Bt69cW =Y9Wy -----END PGP SIGNATURE----- --FX1XXxwkuRo+XMsw-- From owner-freebsd-arch@FreeBSD.ORG Wed Mar 20 11:14:33 2013 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9828DE17 for ; Wed, 20 Mar 2013 11:14:33 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail13.syd.optusnet.com.au (mail13.syd.optusnet.com.au [211.29.132.194]) by mx1.freebsd.org (Postfix) with ESMTP id 33809F5C for ; Wed, 20 Mar 2013 11:14:32 +0000 (UTC) Received: from c211-30-173-106.carlnfd1.nsw.optusnet.com.au (c211-30-173-106.carlnfd1.nsw.optusnet.com.au [211.30.173.106]) by mail13.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id r2KBEHXO005520 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Mar 2013 22:14:20 +1100 Date: Wed, 20 Mar 2013 22:14:17 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Doug Ambrisko Subject: Re: Increase the mount path to MAXPATHLEN? In-Reply-To: <20130319201145.GA19260@ambrisko.com> Message-ID: <20130320211433.F1007@besplex.bde.org> References: <20130319201145.GA19260@ambrisko.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.0 cv=L4xF2Jv8 c=1 sm=1 a=irKjImMqKNAA:10 a=kj9zAlcOel0A:10 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=YZcamMsAmuoA:10 a=BUiG9MIwPJjOGKL8dl8A:9 a=CjuIK1q_8ugA:10 a=oQh-wOpITFmlJKOk:21 a=QHnQFAiQZv-guDTr:21 a=TEtd8y5WR3g2ypngnwZWYw==:117 Cc: arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 11:14:33 -0000 On Tue, 19 Mar 2013, Doug Ambrisko wrote: > At work we use lots of chroots and mount things within those chroots > like dev, proc etc. so it looks like a running system. We also do > some trickery so that we chroot into different versions of FreeBSD > and pull in some of the native binaries so things like mount, ps etc. > work inside. We will also create chroots inside that. Since these > things live in home directories and mount points can be in various > tree's the mount points are getting pretty long. It seems that > checking before was weak and let some of these mount worked by accident > in prior versions of FreeBSD. Old versions worked correctly. Presumably this was not accidental. > Now there is better error checking and > the mounts fail since it exceeds MNAMELEN which was 88. I did notice Now there is broken error checking. Mounting is broken just because the data structure (struct statfs) is incapable of holding the full path length. But often nothing needs to know the full path. It is used mainly by df to report mounted file systems, and 88 is already too long for that. df output on freefall is unreadable due to filesystem name lengths of merely about 30. File systems are also incapable of holding the full path length in their super blocks. This is used mainly for "last mounted on" diagnostic messages in mount() and maybe fsck. It would be even more obviously broken to disallow mounting just because this data structure is too small. Despite its obvious brokenness, ext2fs does it, but currently has no effect since although ext2fs's superblock limit is smaller than 88, the check uses ext2fs's in-core superblock limit which is larger than 88 though smaller than MAXPATHLEN. The larger in-core name is completely useless, since broken mount prevents it all being used and the smaller superblock name prevents it being used usefully (the precise sizes are 64 for the disk and 512 for in-core). In ffs, the sizes are 468 for the disk and in-core. The broken mount prevents most of the 468 from being used. > before that sometimes unmount would unmount other things and could > be an issues with multiple scripts running at the same time. This > doesn't seem to be a problem now. Since the pathname reported by statfs() is now complete, it is unique. The old version should have modified the truncated pathnames in some way so that they are unique. They would never match any pathname to a mount point. Actually, if they are unique then they can be used to look up the non-truncated pathnames. > I'd like to bump the mount point to support a larger value then > MNAMELEN (88) and to some what avoid this problem in the future thought > we should just use MAXPATHLEN. I figure that once start hitting that > limit probably a bunch of things are going to pop up. The limited has been hittable for ~30 years, but rarely hit. If it were important, then it would have been expanded when statfs was expanded to support 64-bit sizes on 32-bit systems. Instead, the pathname arrays have shrunk a bit since 4.4BSD where they had size 90. Before that, bits of the pathnames were bitten off to make space for more important fields, and the array size was reduced to 80 in struct ostatfs. THe current struct statfs just unbites for these fields and expands back to size 80. Does using MAXPATHLEN even fix the problem? Absolute pathnames much longer than it can be constructed using relative paths starting in a deep directory, or symlinks. I think mount(2) handle relative paths, but mount(8) uses realpath(3) and the latter is almost necessary for making the pathnames returned by statfs() usable. realpath() is broken as designed. It repeats the design errors of getwd() and only supports pathname lengths of < {PATH_MAX}. This "fixes" the problem that the path length might be longer than that by not supporting such paths. NetBSD "fixed" this long ago by keeping struct statfs unchanged but deprecated, but using _VFS_MNAMELEN = 1024 in struct statvfs. In FreeBSD, statvfs() and struct statvfs are just minimal compatibility cruft, with no names at all in the struct since names are nonstandard. > This means we'll need to create new system calls for stat calls > and compatibility. It is a pain, since you need to build and install > a new kernel before you can run code with the new values. So there > is some pain involved. I've made this change locally on a system Too much pain for me. I still use statfs = ostatfs in sys/syscall.h so that the same (statically linked) userland works on a range of kernels going back to ones that don't have statfs. But since I don't use current userlands I don't really care. Bruce From owner-freebsd-arch@FreeBSD.ORG Wed Mar 20 16:23:05 2013 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 17B3080A for ; Wed, 20 Mar 2013 16:23:05 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id E553528B for ; Wed, 20 Mar 2013 16:23:04 +0000 (UTC) Received: from Alfreds-MacBook-Pro-9.local (c-67-180-208-218.hsd1.ca.comcast.net [67.180.208.218]) by elvis.mu.org (Postfix) with ESMTPSA id 77E9A1A3D58; Wed, 20 Mar 2013 09:22:54 -0700 (PDT) Message-ID: <5149E257.7030906@mu.org> Date: Wed, 20 Mar 2013 09:22:47 -0700 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Bruce Evans Subject: Re: Increase the mount path to MAXPATHLEN? References: <20130319201145.GA19260@ambrisko.com> <20130320211433.F1007@besplex.bde.org> In-Reply-To: <20130320211433.F1007@besplex.bde.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 16:23:05 -0000 On 3/20/13 4:14 AM, Bruce Evans wrote: > On Tue, 19 Mar 2013, Doug Ambrisko wrote: > >> At work we use lots of chroots and mount things within those chroots >> like dev, proc etc. so it looks like a running system. We also do >> some trickery so that we chroot into different versions of FreeBSD >> and pull in some of the native binaries so things like mount, ps etc. >> work inside. We will also create chroots inside that. Since these >> things live in home directories and mount points can be in various >> tree's the mount points are getting pretty long. It seems that >> checking before was weak and let some of these mount worked by accident >> in prior versions of FreeBSD. > >> I'd like to bump the mount point to support a larger value then >> MNAMELEN (88) and to some what avoid this problem in the future thought >> we should just use MAXPATHLEN. I figure that once start hitting that >> limit probably a bunch of things are going to pop up. > > The limited has been hittable for ~30 years, but rarely hit. If it were > important, then it would have been expanded when statfs was expanded to > support 64-bit sizes on 32-bit systems. Instead, the pathname arrays > have shrunk a bit since 4.4BSD where they had size 90. Before that, > bits of the pathnames were bitten off to make space for more important > fields, and the array size was reduced to 80 in struct ostatfs. THe > current struct statfs just unbites for these fields and expands back to > size 80. > > Does using MAXPATHLEN even fix the problem? Absolute pathnames much > longer than it can be constructed using relative paths starting in > a deep directory, or symlinks. I think mount(2) handle relative paths, > but mount(8) uses realpath(3) and the latter is almost necessary for > making the pathnames returned by statfs() usable. realpath() is broken > as designed. It repeats the design errors of getwd() and only supports > pathname lengths of < {PATH_MAX}. This "fixes" the problem that the > path length might be longer than that by not supporting such paths. > > NetBSD "fixed" this long ago by keeping struct statfs unchanged but > deprecated, but using _VFS_MNAMELEN = 1024 in struct statvfs. In > FreeBSD, > statvfs() and struct statvfs are just minimal compatibility cruft, with > no names at all in the struct since names are nonstandard. This is the approach I would hope to see happen. Making a separate syscall/method to return a MAXPATHLEN mount path based on fsid would be very easy and result in a lot less compat cruft. I think it's time to deprecate retrieval of the mount paths via statfs and instead use another call as do most other unix-like OSes. -Alfred From owner-freebsd-arch@FreeBSD.ORG Wed Mar 20 18:11:21 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7539B624 for ; Wed, 20 Mar 2013 18:11:21 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from mail.ambrisko.com (mail.ambrisko.com [70.91.206.90]) by mx1.freebsd.org (Postfix) with ESMTP id 4C1B8B49 for ; Wed, 20 Mar 2013 18:11:21 +0000 (UTC) X-Ambrisko-Me: Yes Received: from server2.ambrisko.com (HELO internal.ambrisko.com) ([192.168.1.2]) by ironport.ambrisko.com with ESMTP; 20 Mar 2013 11:13:54 -0700 Received: from ambrisko.com (localhost [127.0.0.1]) by internal.ambrisko.com (8.14.4/8.14.4) with ESMTP id r2KIBKwC002779; Wed, 20 Mar 2013 11:11:20 -0700 (PDT) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.14.4/8.14.4/Submit) id r2KIBKHq002758; Wed, 20 Mar 2013 11:11:20 -0700 (PDT) (envelope-from ambrisko) Date: Wed, 20 Mar 2013 11:11:20 -0700 From: Doug Ambrisko To: Alfred Perlstein Subject: Re: Increase the mount path to MAXPATHLEN? Message-ID: <20130320181120.GA52086@ambrisko.com> References: <20130319201145.GA19260@ambrisko.com> <20130320211433.F1007@besplex.bde.org> <5149E257.7030906@mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5149E257.7030906@mu.org> User-Agent: Mutt/1.4.2.3i Cc: arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 18:11:21 -0000 On Wed, Mar 20, 2013 at 09:22:47AM -0700, Alfred Perlstein wrote: | On 3/20/13 4:14 AM, Bruce Evans wrote: | >On Tue, 19 Mar 2013, Doug Ambrisko wrote: | > | >>At work we use lots of chroots and mount things within those chroots | >>like dev, proc etc. so it looks like a running system. We also do | >>some trickery so that we chroot into different versions of FreeBSD | >>and pull in some of the native binaries so things like mount, ps etc. | >>work inside. We will also create chroots inside that. Since these | >>things live in home directories and mount points can be in various | >>tree's the mount points are getting pretty long. It seems that | >>checking before was weak and let some of these mount worked by accident | >>in prior versions of FreeBSD. | > | >>I'd like to bump the mount point to support a larger value then | >>MNAMELEN (88) and to some what avoid this problem in the future thought | >>we should just use MAXPATHLEN. I figure that once start hitting that | >>limit probably a bunch of things are going to pop up. | > | >The limited has been hittable for ~30 years, but rarely hit. If it were | >important, then it would have been expanded when statfs was expanded to | >support 64-bit sizes on 32-bit systems. Instead, the pathname arrays | >have shrunk a bit since 4.4BSD where they had size 90. Before that, | >bits of the pathnames were bitten off to make space for more important | >fields, and the array size was reduced to 80 in struct ostatfs. THe | >current struct statfs just unbites for these fields and expands back to | >size 80. | > | >Does using MAXPATHLEN even fix the problem? Absolute pathnames much | >longer than it can be constructed using relative paths starting in | >a deep directory, or symlinks. I think mount(2) handle relative paths, | >but mount(8) uses realpath(3) and the latter is almost necessary for | >making the pathnames returned by statfs() usable. realpath() is broken | >as designed. It repeats the design errors of getwd() and only supports | >pathname lengths of < {PATH_MAX}. This "fixes" the problem that the | >path length might be longer than that by not supporting such paths. | > | >NetBSD "fixed" this long ago by keeping struct statfs unchanged but | >deprecated, but using _VFS_MNAMELEN = 1024 in struct statvfs. In | >FreeBSD, | >statvfs() and struct statvfs are just minimal compatibility cruft, with | >no names at all in the struct since names are nonstandard. | | This is the approach I would hope to see happen. Making a separate | syscall/method to return a MAXPATHLEN mount path based on fsid would be | very easy and result in a lot less compat cruft. | | I think it's time to deprecate retrieval of the mount paths via statfs | and instead use another call as do most other unix-like OSes. Okay, looks like I'll have to look into this some more. I wasn't testing with disk file system, just mounting stuff via nullfs, devfs, procfs etc. As for this working before, it seems like on older FreeBSD version like 8.2 if you were in a chroot and did a mount of devfs to a local directory like dest/dev then it worked. If you do it outside then chroot root then it fails. With 9.1 and -current this fails now inside the chroot. mount reports the path as done relative to the chroot. mount in 9.1 reports the full path as if it was outside the chroot. This somewhat makes sense to what I've observed in the past since I use a lot of chroots to as work sand boxes. What I found if I ran build scripts concurrently, that things would get umounted sometimes from the wrong chroot. Maybe due to this being ambigious. Now with full paths being recorded this doesn't seem to happen now. Thanks, Doug A. From owner-freebsd-arch@FreeBSD.ORG Wed Mar 20 18:43:51 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C38AAABE; Wed, 20 Mar 2013 18:43:51 +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 9BB94D26; Wed, 20 Mar 2013 18:43:51 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id C8192B915; Wed, 20 Mar 2013 14:43:50 -0400 (EDT) From: John Baldwin To: freebsd-arch@freebsd.org Subject: Re: Increase the mount path to MAXPATHLEN? Date: Wed, 20 Mar 2013 09:09:54 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <20130319201145.GA19260@ambrisko.com> <20130320102116.GA3794@kib.kiev.ua> In-Reply-To: <20130320102116.GA3794@kib.kiev.ua> MIME-Version: 1.0 Message-Id: <201303200909.54555.jhb@freebsd.org> Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 20 Mar 2013 14:43:50 -0400 (EDT) Cc: Konstantin Belousov , arch@freebsd.org, gleb@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 18:43:51 -0000 On Wednesday, March 20, 2013 6:21:16 am Konstantin Belousov wrote: > On Tue, Mar 19, 2013 at 01:11:45PM -0700, Doug Ambrisko wrote: > > I have a patch at: > > http://people.freebsd.org/~ambrisko/statf.patch > > that people can glance at. If this approach is the right way to go > > then I update it for the latest -current and update it. > > No, I do not think this is the right approach. > You are breaking the ABI in the backward-incompatible way. > > What should be done is versioning the fstatfs(2) and other related > symbols from libc. Please look at the lib/libc/include/compat.h > and its use for upgrading the syscalls ABI. Not sufficient. This will not help static binaries or binaries using an older libc (such as libc.so.6) if that libc used these system call vectors. I know we rototilled all the stat system calls for 64-bit ino_t recently, not sure if that also affected statfs. If it did then you might be off the hook for libc.so.6, but static binaries still matter as long as we ship a libc.a. However, it is true that in addition to new system calls, you now also need to add new versions of the relevant functions via symbol versioning in libc as well. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Wed Mar 20 18:56:52 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 779533C9; Wed, 20 Mar 2013 18:56:52 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 19D77E15; Wed, 20 Mar 2013 18:56:51 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r2KIueIA071470; Wed, 20 Mar 2013 20:56:40 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.0 kib.kiev.ua r2KIueIA071470 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r2KIueK8071469; Wed, 20 Mar 2013 20:56:40 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 20 Mar 2013 20:56:39 +0200 From: Konstantin Belousov To: John Baldwin Subject: Re: Increase the mount path to MAXPATHLEN? Message-ID: <20130320185639.GI3794@kib.kiev.ua> References: <20130319201145.GA19260@ambrisko.com> <20130320102116.GA3794@kib.kiev.ua> <201303200909.54555.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7ny1L16MQneaJ3Er" Content-Disposition: inline In-Reply-To: <201303200909.54555.jhb@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: arch@freebsd.org, gleb@freebsd.org, freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 18:56:52 -0000 --7ny1L16MQneaJ3Er Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 20, 2013 at 09:09:54AM -0400, John Baldwin wrote: > On Wednesday, March 20, 2013 6:21:16 am Konstantin Belousov wrote: > > On Tue, Mar 19, 2013 at 01:11:45PM -0700, Doug Ambrisko wrote: > > > I have a patch at: > > > http://people.freebsd.org/~ambrisko/statf.patch > > > that people can glance at. If this approach is the right way to go > > > then I update it for the latest -current and update it. > >=20 > > No, I do not think this is the right approach. > > You are breaking the ABI in the backward-incompatible way. > > > > What should be done is versioning the fstatfs(2) and other related > > symbols from libc. Please look at the lib/libc/include/compat.h > > and its use for upgrading the syscalls ABI. >=20 > Not sufficient. This will not help static binaries or binaries using an > older libc (such as libc.so.6) if that libc used these system call vector= s. > I know we rototilled all the stat system calls for 64-bit ino_t recently, > not sure if that also affected statfs. If it did then you might be off > the hook for libc.so.6, but static binaries still matter as long as we > ship a libc.a. I do not see why. Old static binaries, as well old libc.so.6 and libc.so.7, would use old syscall numbers. New libc.so.7 use new syscall number, but export fstatfs@FBSD_1.0 which is resolved for the old binaries, resulting in old binaries calling old syscall. >=20 > However, it is true that in addition to new system calls, you now also ne= ed > to add new versions of the relevant functions via symbol versioning in li= bc > as well. --7ny1L16MQneaJ3Er Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRSgZnAAoJEJDCuSvBvK1BavEP/0RgDDnoqSNTW4D151xDO18F 9m4nOB0SiDTwvTXCGvqV2pu9fBaUuvlVd972y70iDAWiAHNxKkEBRRhbnyC6cyY2 sMs26Mrwjz4NUI2wu9rsonkRjEeITmmEyj7UgDVXFzsprjBEWx94eFZKLFV1M4CW Fg15qlZKDl4xCCKiAhBHsrRXlUsnJdu73n6D6R+6Fc17G6Wtq3LMgkMMBJmqQ/v8 VeBRuDTC58l5pWy2SAJrDNW1ffl5T/uSfVg7jixq3uWvBDcy4QfW4I0pHY4JGhcH 9gxpNkBsV/P9G9im21WTbSEfRhrtDh0b1zBUgpmrN2VdRFe8uwp91bYAwPCAF3Dv XGCPgG8RUGE1lF9l/qWiwokGH7Ui2UE8aAmn1Clr4ikMBgEBWCZ/Uu16L9vtw0MF FNTJd5iFozIzfVghlylQ43eC4hyReg9rAiCo3Q92ny+bx+62lgHpdO9wmdAUMpcr 9vxzaQw6jYW19qPYy+UnKtALspcjYQEKP9BRqjpq9aTmTqb4idVO+82AOGNyQcJN d18Dq9ywYm/dtsthHE3QdCf0apyJqgmA8TLz7YExNVyB2JP1IzKzepzAuTuH3x44 Kk+2sPlWcbIXybuGN/+rVYTSTrvuJwgWvx+qoKSKKI83nq0NF3d7zbIwoCRa6ajx ORijeYfXEG9KZ2Qq/OLi =2l5b -----END PGP SIGNATURE----- --7ny1L16MQneaJ3Er-- From owner-freebsd-arch@FreeBSD.ORG Wed Mar 20 22:00:47 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C0B7D45C; Wed, 20 Mar 2013 22:00:47 +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 9BE5E7C3; Wed, 20 Mar 2013 22:00:47 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id EA053B917; Wed, 20 Mar 2013 18:00:46 -0400 (EDT) From: John Baldwin To: Konstantin Belousov Subject: Re: Increase the mount path to MAXPATHLEN? Date: Wed, 20 Mar 2013 18:00:37 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <20130319201145.GA19260@ambrisko.com> <201303200909.54555.jhb@freebsd.org> <20130320185639.GI3794@kib.kiev.ua> In-Reply-To: <20130320185639.GI3794@kib.kiev.ua> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201303201800.38090.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 20 Mar 2013 18:00:47 -0400 (EDT) Cc: arch@freebsd.org, gleb@freebsd.org, freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 22:00:47 -0000 On Wednesday, March 20, 2013 2:56:39 pm Konstantin Belousov wrote: > On Wed, Mar 20, 2013 at 09:09:54AM -0400, John Baldwin wrote: > > On Wednesday, March 20, 2013 6:21:16 am Konstantin Belousov wrote: > > > On Tue, Mar 19, 2013 at 01:11:45PM -0700, Doug Ambrisko wrote: > > > > I have a patch at: > > > > http://people.freebsd.org/~ambrisko/statf.patch > > > > that people can glance at. If this approach is the right way to go > > > > then I update it for the latest -current and update it. > > > > > > No, I do not think this is the right approach. > > > You are breaking the ABI in the backward-incompatible way. > > > > > > What should be done is versioning the fstatfs(2) and other related > > > symbols from libc. Please look at the lib/libc/include/compat.h > > > and its use for upgrading the syscalls ABI. > > > > Not sufficient. This will not help static binaries or binaries using an > > older libc (such as libc.so.6) if that libc used these system call vectors. > > I know we rototilled all the stat system calls for 64-bit ino_t recently, > > not sure if that also affected statfs. If it did then you might be off > > the hook for libc.so.6, but static binaries still matter as long as we > > ship a libc.a. > I do not see why. Old static binaries, as well old libc.so.6 and libc.so.7, > would use old syscall numbers. New libc.so.7 use new syscall number, but > export fstatfs@FBSD_1.0 which is resolved for the old binaries, resulting > in old binaries calling old syscall. Right. I thought you were objecting to his adding new system calls and wanted to only add wrappers in libc where the compat symbols in libc called the new system calls and thunked the data. > > However, it is true that in addition to new system calls, you now also need > > to add new versions of the relevant functions via symbol versioning in libc > > as well. I guess you were just saying that Doug needs this additional step, and I concur with that entirely. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Wed Mar 20 22:05:14 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C19CF6E6; Wed, 20 Mar 2013 22:05:14 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from mail.ambrisko.com (mail.ambrisko.com [70.91.206.90]) by mx1.freebsd.org (Postfix) with ESMTP id 926BC7F0; Wed, 20 Mar 2013 22:05:14 +0000 (UTC) X-Ambrisko-Me: Yes Received: from server2.ambrisko.com (HELO internal.ambrisko.com) ([192.168.1.2]) by ironport.ambrisko.com with ESMTP; 20 Mar 2013 15:07:42 -0700 Received: from ambrisko.com (localhost [127.0.0.1]) by internal.ambrisko.com (8.14.4/8.14.4) with ESMTP id r2KM55gk085896; Wed, 20 Mar 2013 15:05:05 -0700 (PDT) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.14.4/8.14.4/Submit) id r2KM550g085895; Wed, 20 Mar 2013 15:05:05 -0700 (PDT) (envelope-from ambrisko) Date: Wed, 20 Mar 2013 15:05:05 -0700 From: Doug Ambrisko To: John Baldwin Subject: Re: Increase the mount path to MAXPATHLEN? Message-ID: <20130320220505.GA84878@ambrisko.com> References: <20130319201145.GA19260@ambrisko.com> <201303200909.54555.jhb@freebsd.org> <20130320185639.GI3794@kib.kiev.ua> <201303201800.38090.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201303201800.38090.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: Konstantin Belousov , arch@freebsd.org, gleb@freebsd.org, freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 22:05:14 -0000 On Wed, Mar 20, 2013 at 06:00:37PM -0400, John Baldwin wrote: | On Wednesday, March 20, 2013 2:56:39 pm Konstantin Belousov wrote: | > On Wed, Mar 20, 2013 at 09:09:54AM -0400, John Baldwin wrote: | > > On Wednesday, March 20, 2013 6:21:16 am Konstantin Belousov wrote: | > > > On Tue, Mar 19, 2013 at 01:11:45PM -0700, Doug Ambrisko wrote: | > > > > I have a patch at: | > > > > http://people.freebsd.org/~ambrisko/statf.patch | > > > > that people can glance at. If this approach is the right way to go | > > > > then I update it for the latest -current and update it. | > > > | > > > No, I do not think this is the right approach. | > > > You are breaking the ABI in the backward-incompatible way. | > > > | > > > What should be done is versioning the fstatfs(2) and other related | > > > symbols from libc. Please look at the lib/libc/include/compat.h | > > > and its use for upgrading the syscalls ABI. | > > | > > Not sufficient. This will not help static binaries or binaries using an | > > older libc (such as libc.so.6) if that libc used these system call vectors. | > > I know we rototilled all the stat system calls for 64-bit ino_t recently, | > > not sure if that also affected statfs. If it did then you might be off | > > the hook for libc.so.6, but static binaries still matter as long as we | > > ship a libc.a. | > I do not see why. Old static binaries, as well old libc.so.6 and libc.so.7, | > would use old syscall numbers. New libc.so.7 use new syscall number, but | > export fstatfs@FBSD_1.0 which is resolved for the old binaries, resulting | > in old binaries calling old syscall. | | Right. I thought you were objecting to his adding new system calls and wanted | to only add wrappers in libc where the compat symbols in libc called the new | system calls and thunked the data. | | > > However, it is true that in addition to new system calls, you now also need | > > to add new versions of the relevant functions via symbol versioning in libc | > > as well. | | I guess you were just saying that Doug needs this additional step, and I concur | with that entirely. Yes, since if I did that then there wouldn't be the upgrade hassle. So that was a good point that I had forgot about. Thanks, Doug A. From owner-freebsd-arch@FreeBSD.ORG Wed Mar 20 22:32:38 2013 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9F349BBE for ; Wed, 20 Mar 2013 22:32:38 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (unknown [IPv6:2001:610:1108:5012::107]) by mx1.freebsd.org (Postfix) with ESMTP id 6A1168D1 for ; Wed, 20 Mar 2013 22:32:38 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 411331203C1; Wed, 20 Mar 2013 23:32:21 +0100 (CET) Received: by snail.stack.nl (Postfix, from userid 1677) id 28A462848C; Wed, 20 Mar 2013 23:32:21 +0100 (CET) Date: Wed, 20 Mar 2013 23:32:21 +0100 From: Jilles Tjoelker To: Alfred Perlstein Subject: Re: Increase the mount path to MAXPATHLEN? Message-ID: <20130320223220.GA54813@stack.nl> References: <20130319201145.GA19260@ambrisko.com> <20130320211433.F1007@besplex.bde.org> <5149E257.7030906@mu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5149E257.7030906@mu.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 22:32:38 -0000 On Wed, Mar 20, 2013 at 09:22:47AM -0700, Alfred Perlstein wrote: > This is the approach I would hope to see happen. Making a separate > syscall/method to return a MAXPATHLEN mount path based on fsid would be > very easy and result in a lot less compat cruft. > I think it's time to deprecate retrieval of the mount paths via statfs > and instead use another call as do most other unix-like OSes. I like this idea but if it is based on fsid it will only work for root. A lookup by st_dev can be allowed for all users but st_dev may be less unique. The lookup can probably be implemented as a sysctl. This idea also solves the potential problem of getfsstat(2) returning a very large amount of data if struct statfs contains 2K of buffers and there are many mounted filesystems. This would still be rather different from what Linux does. Linux does not have anything like our getfsstat(2). Instead, /etc/mtab or /proc/mounts contains an fstab-like list of mounts and df(1) calls statfs(2) for each of them. I don't like this because the statfs call will take vnode locks and does not support a MNT_NOWAIT flag, so it will break df -n. -- Jilles Tjoelker From owner-freebsd-arch@FreeBSD.ORG Thu Mar 21 03:43:41 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 71B88D1F for ; Thu, 21 Mar 2013 03:43:41 +0000 (UTC) (envelope-from gleb.kurtsou@gmail.com) Received: from mail-da0-x22c.google.com (mail-da0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) by mx1.freebsd.org (Postfix) with ESMTP id 4D4D2683 for ; Thu, 21 Mar 2013 03:43:41 +0000 (UTC) Received: by mail-da0-f44.google.com with SMTP id z20so1376114dae.17 for ; Wed, 20 Mar 2013 20:43:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=92ut8INRufI06KyA8jIZGKvQK1j4OX0kQAYZ7wtzaO0=; b=VzfSKhJfzuKgm3ZrylF5bzc4rID51jhm/AYZOD4DuAXxZesVkVLqG/wJ0D3JwpIfQE cy6t6/MOQSwAnvsiT0bJBfbzeUds/54Xkdq+Q5EzH08UbyKhBmPdnFDIvoEahehopsRU oItfZLVrIwnVR9wQMQ3PAwR5Cjk/IGmbr5eqEli1q9RlOw6AEAOeInY7W7Qzqu5n1tIe W+UpVJwxyJR0flYWgPdMyuTEuzUK/NHoEktywc6R+/KauK0cGO2pZKAhYusdz09WJqub 9Poh9vyLqIHXhX736lBl9v4zvOqEYPQywamX+Gqk/DNFz4083NB6f7p5yvD+gQP1QDsD e2ZA== X-Received: by 10.66.255.99 with SMTP id ap3mr13000136pad.102.1363837420565; Wed, 20 Mar 2013 20:43:40 -0700 (PDT) Received: from localhost (c-67-160-248-74.hsd1.ca.comcast.net. [67.160.248.74]) by mx.google.com with ESMTPS id kl4sm4370340pbc.31.2013.03.20.20.43.38 (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 Mar 2013 20:43:39 -0700 (PDT) Date: Wed, 20 Mar 2013 20:43:40 -0700 From: Gleb Kurtsou To: Konstantin Belousov Subject: Re: Increase the mount path to MAXPATHLEN? Message-ID: <20130321034340.GA1120@reks> References: <20130319201145.GA19260@ambrisko.com> <20130320102116.GA3794@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20130320102116.GA3794@kib.kiev.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 03:43:41 -0000 On (20/03/2013 12:21), Konstantin Belousov wrote: > On Tue, Mar 19, 2013 at 01:11:45PM -0700, Doug Ambrisko wrote: > > I have a patch at: > > http://people.freebsd.org/~ambrisko/statf.patch > > that people can glance at. If this approach is the right way to go > > then I update it for the latest -current and update it. > > No, I do not think this is the right approach. > You are breaking the ABI in the backward-incompatible way. > > What should be done is versioning the fstatfs(2) and other related > symbols from libc. Please look at the lib/libc/include/compat.h > and its use for upgrading the syscalls ABI. MNAMELEN switch to 1024 was implemented during GSoc 2011. https://github.com/glk/freebsd-ino64/commit/f2b990cf8861bb72d4477b39426cbe33f95ffcdf freebsd-ino64 repo should contain most recent code, I'll double check during weekend. It also contains patch to change dev_t to 64 bit. https://github.com/glk/freebsd-ino64/commits/projects/ino64 Konstantin, do you think it's worth pushing ino64 into CURRENT considering 10.0 is approaching? The only unresolved issue I can recall is ABI breakage in audit syscalls, providing compat shims for them wasn't straightforward due to complex structure. Unfortunately I've been swamped at $JOB for a while now and had no time to clean it up and commit. So if somebody is willing to help please contact me. > Also, the whole ABI of the system should be inspected for the changes, > due to possible use of the struct statfs in other structures, or as > an argument to other functions. > > Gleb Kurtsou (gleb@) has a tool which could compare a set of the shlibs > before and after change for the ABI drift, using the dward debugging > information. I do not remember where it is stored, definitely worth > committing somewhere at tools/tools. https://github.com/glk/shlib-compat From owner-freebsd-arch@FreeBSD.ORG Thu Mar 21 14:14:49 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 152CF207 for ; Thu, 21 Mar 2013 14:14:49 +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 E739FCFC for ; Thu, 21 Mar 2013 14:14:48 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 26212B91A; Thu, 21 Mar 2013 10:14:48 -0400 (EDT) From: John Baldwin To: freebsd-arch@freebsd.org Subject: Re: Increase the mount path to MAXPATHLEN? Date: Thu, 21 Mar 2013 09:44:04 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <20130319201145.GA19260@ambrisko.com> <20130320102116.GA3794@kib.kiev.ua> <20130321034340.GA1120@reks> In-Reply-To: <20130321034340.GA1120@reks> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201303210944.04443.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 21 Mar 2013 10:14:48 -0400 (EDT) Cc: Konstantin Belousov , Gleb Kurtsou X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 14:14:49 -0000 On Wednesday, March 20, 2013 11:43:40 pm Gleb Kurtsou wrote: > On (20/03/2013 12:21), Konstantin Belousov wrote: > > On Tue, Mar 19, 2013 at 01:11:45PM -0700, Doug Ambrisko wrote: > > > I have a patch at: > > > http://people.freebsd.org/~ambrisko/statf.patch > > > that people can glance at. If this approach is the right way to go > > > then I update it for the latest -current and update it. > > > > No, I do not think this is the right approach. > > You are breaking the ABI in the backward-incompatible way. > > > > What should be done is versioning the fstatfs(2) and other related > > symbols from libc. Please look at the lib/libc/include/compat.h > > and its use for upgrading the syscalls ABI. > > MNAMELEN switch to 1024 was implemented during GSoc 2011. > https://github.com/glk/freebsd- ino64/commit/f2b990cf8861bb72d4477b39426cbe33f95ffcdf > > freebsd-ino64 repo should contain most recent code, I'll double check > during weekend. It also contains patch to change dev_t to 64 bit. > > https://github.com/glk/freebsd-ino64/commits/projects/ino64 > > Konstantin, do you think it's worth pushing ino64 into CURRENT > considering 10.0 is approaching? The only unresolved issue I can recall > is ABI breakage in audit syscalls, providing compat shims for them > wasn't straightforward due to complex structure. > > Unfortunately I've been swamped at $JOB for a while now and had no time > to clean it up and commit. So if somebody is willing to help please > contact me. Oh, I thought this was in 10.0. I think we should get this into 10.0 if at all possible. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Fri Mar 22 05:20:20 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2687B919; Fri, 22 Mar 2013 05:20:20 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail13.syd.optusnet.com.au (mail13.syd.optusnet.com.au [211.29.132.194]) by mx1.freebsd.org (Postfix) with ESMTP id B99971A4; Fri, 22 Mar 2013 05:20:19 +0000 (UTC) Received: from c211-30-173-106.carlnfd1.nsw.optusnet.com.au (c211-30-173-106.carlnfd1.nsw.optusnet.com.au [211.30.173.106]) by mail13.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id r2M5KF3u008099 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Mar 2013 16:20:17 +1100 Date: Fri, 22 Mar 2013 16:20:15 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Pawel Jakub Dawidek Subject: Re: chflags(2)'s flags argument. In-Reply-To: <20130318210817.GA1367@garage.freebsd.pl> Message-ID: <20130322155410.D953@besplex.bde.org> References: <20130317003559.GA1364@garage.freebsd.pl> <20130317064123.GM3794@kib.kiev.ua> <20130317111112.GC1364@garage.freebsd.pl> <20130317155743.GR3794@kib.kiev.ua> <20130317162021.GG1364@garage.freebsd.pl> <20130317162533.GT3794@kib.kiev.ua> <20130317164632.GI1364@garage.freebsd.pl> <20130317174205.GU3794@kib.kiev.ua> <20130317211027.GJ1364@garage.freebsd.pl> <20130318155059.V925@besplex.bde.org> <20130318210817.GA1367@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.0 cv=ZZ1FrbpA c=1 sm=1 a=mueDxCsUSoQA:10 a=kj9zAlcOel0A:10 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=IpFD8tbXDcUA:10 a=CRbpp6TccLSmc3ZaovoA:9 a=CjuIK1q_8ugA:10 a=TEtd8y5WR3g2ypngnwZWYw==:117 Cc: Konstantin Belousov , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 05:20:20 -0000 On Mon, 18 Mar 2013, Pawel Jakub Dawidek wrote: > On Mon, Mar 18, 2013 at 04:51:22PM +1100, Bruce Evans wrote: >> On Sun, 17 Mar 2013, Pawel Jakub Dawidek wrote: >>> Maybe we could arrange ports build with lchflags(2) changed to take >>> unsigned long to see how destructive the change really is, because my >>> expectation is that not very. >> >> Why not use the correct type (u_int)? u_long is just too long, since >> st_flags is only 32 bits, so much larger and realler API and ABI changes >> would be needed to support more than 32 flags. > > I'd prefer leave u_long, as it breaks API as little as possible. This is > also the type that's being used by consumers of this API, as it was > documented in chflags(2) since forever. Also, as I already mentioned, > strtofflags(3) and fflagstostr(3) uses this type too. When changing an API, it is best to change it in the correct direction. >> The garbage also has some style bugs. It spells "unsigned long" as >> itself. All other code in chflags.c still uses the normal abbreviation >> u_long. > > Using u_long for chflags() prototypes in sys/stat.h will only work, > because of this: > > #if !defined(_KERNEL) && __BSD_VISIBLE > /* > * XXX We get miscellaneous namespace pollution with this. > */ > #include > #endif > > As sys/time.h will include sys/types.h, eventhough sys/stat.h is trying > to avoid that at the begining. I wrote the comment. mike@(gone) fixed the prototypes for *chflags() so that they don't depend on the namespace pollution. But sys/time.h still has massive namespace pollution with many other dependences on the pollution in sys/types.h. Of coarse the header must not use the polluting spelling, but the implementation can use any spelling it wants. Actually the header should use the flags type __fflags_t. That is __uint32_t. This is currently unusuable since the prototypes are incompatible with it. Changing the prototypes to it would fix them in the way that I want. Fixed-width types in APIs are design errors, but we don't worry about that for mode_t, uid_t, ... 32-bit fixed width types cause fewer problems than most since vax is the only supported arch so ints are always 32 bits. In glibc-2.6, chflags() takes type int for hurd and the default chflags() (a stub that returns ENOSYS) also takes int. So in ~20 years when POSIX gets around to standardizing this, it would have to use a typedefed type like fflags_t, and to support the FreeBSD mistakes it would need different types for struct stat and the prototypes. In linux-2.6.10, file flags are set by ioctl(). ioctl() in linux has almost the same prototype as in BSD, so the arg type is unsigned long. glibc-2.6 doesn't have any special support for this ioctl, and the flags bits depend on the fs for both their name and their number, so file flags are or were even harder to use in Linux than in FreeBSD, and further from being standardizable. glibc-2.6 has an fs-independent bit in mount.h, with a warning that only newer systems support it. linux-2.6.10 is too old to support it. Bruce From owner-freebsd-arch@FreeBSD.ORG Fri Mar 22 06:10:35 2013 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3BA32567 for ; Fri, 22 Mar 2013 06:10:35 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from fallbackmx07.syd.optusnet.com.au (fallbackmx07.syd.optusnet.com.au [211.29.132.9]) by mx1.freebsd.org (Postfix) with ESMTP id 2985538E for ; Fri, 22 Mar 2013 06:10:33 +0000 (UTC) Received: from mail10.syd.optusnet.com.au (mail10.syd.optusnet.com.au [211.29.132.191]) by fallbackmx07.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id r2M6AQUp013408 for ; Fri, 22 Mar 2013 17:10:26 +1100 Received: from c211-30-173-106.carlnfd1.nsw.optusnet.com.au (c211-30-173-106.carlnfd1.nsw.optusnet.com.au [211.30.173.106]) by mail10.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id r2M6ADfu027410 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Mar 2013 17:10:14 +1100 Date: Fri, 22 Mar 2013 17:10:12 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Alfred Perlstein Subject: Re: Increase the mount path to MAXPATHLEN? In-Reply-To: <5149E257.7030906@mu.org> Message-ID: <20130322162905.M953@besplex.bde.org> References: <20130319201145.GA19260@ambrisko.com> <20130320211433.F1007@besplex.bde.org> <5149E257.7030906@mu.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.0 cv=D5QfsYtj c=1 sm=1 a=irKjImMqKNAA:10 a=kj9zAlcOel0A:10 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=YZcamMsAmuoA:10 a=AhFODrc5t8sULCTFUCMA:9 a=CjuIK1q_8ugA:10 a=TEtd8y5WR3g2ypngnwZWYw==:117 Cc: arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 06:10:35 -0000 On Wed, 20 Mar 2013, Alfred Perlstein wrote: > On 3/20/13 4:14 AM, Bruce Evans wrote: >> ... >> NetBSD "fixed" this long ago by keeping struct statfs unchanged but >> deprecated, but using _VFS_MNAMELEN = 1024 in struct statvfs. In FreeBSD, >> statvfs() and struct statvfs are just minimal compatibility cruft, with >> no names at all in the struct since names are nonstandard. > > This is the approach I would hope to see happen. Making a separate > syscall/method to return a MAXPATHLEN mount path based on fsid would be very > easy and result in a lot less compat cruft. Not very easy. jilles mentioned getfsstat(2), and perhaps getmntinfo(3). I didn't notice/remember that getfsstat() is a syscall and that there are technical reasons for them. These APIs _are_ easy to use since it is often necessary to iterated over all mounted file systems. They assemble more info than you usually want in a nice structured form. > I think it's time to deprecate retrieval of the mount paths via statfs and > instead use another call as do most other unix-like OSes. Hmm, some other unixes have a lame struct statfs (like FreeBSD struct statvfs). I hate to advertise the nmount(2) mistake, but if it were properly bloated, then it would include returning the mount paths as a small part of returning all the mount options. Its unstructured data is hard to parse and is still missing returning of anything AFAIK (not far) for either the call itself or for a hypothetical associated call (its iov arg is not declared as const, but is not documented to be modified to return anything). Its bloat doesn't include always allocating MAXPATHLEN bytes for names. Instead, all of its strings are free-format, so they are unstructured instead. If it were usable, then getmntinfo() could retrieve the pathnames from it. The difficulty is to convert the pathnames to a structured form so that clients of getmntinfo() don't see much difference. Pathnames are about the easiest options to convert to a structured form, since there is already a place to put part of them. Note than applications mostly don't use getfsstat() directly. df(1) and mount(1) only use getmntinfo() directly. So most things can be fixed without changing syscalls. Brce From owner-freebsd-arch@FreeBSD.ORG Fri Mar 22 07:49:06 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id AA7055D2 for ; Fri, 22 Mar 2013 07:49:06 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (garage.dawidek.net [91.121.88.72]) by mx1.freebsd.org (Postfix) with ESMTP id 446589B1 for ; Fri, 22 Mar 2013 07:49:06 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id AEC663FA; Fri, 22 Mar 2013 08:45:45 +0100 (CET) Date: Fri, 22 Mar 2013 08:50:46 +0100 From: Pawel Jakub Dawidek To: Bruce Evans Subject: Re: chflags(2)'s flags argument. Message-ID: <20130322075046.GD1356@garage.freebsd.pl> References: <20130317111112.GC1364@garage.freebsd.pl> <20130317155743.GR3794@kib.kiev.ua> <20130317162021.GG1364@garage.freebsd.pl> <20130317162533.GT3794@kib.kiev.ua> <20130317164632.GI1364@garage.freebsd.pl> <20130317174205.GU3794@kib.kiev.ua> <20130317211027.GJ1364@garage.freebsd.pl> <20130318155059.V925@besplex.bde.org> <20130318210817.GA1367@garage.freebsd.pl> <20130322155410.D953@besplex.bde.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0IvGJv3f9h+YhkrH" Content-Disposition: inline In-Reply-To: <20130322155410.D953@besplex.bde.org> X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Konstantin Belousov , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 07:49:06 -0000 --0IvGJv3f9h+YhkrH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable First of all, sorry Bruce, I saw you being active on other threads and assumed you have no other comments so I went ahead and committed this change to not to delay introduction of chflagsat(2) any further. On Fri, Mar 22, 2013 at 04:20:15PM +1100, Bruce Evans wrote: > On Mon, 18 Mar 2013, Pawel Jakub Dawidek wrote: > > I'd prefer leave u_long, as it breaks API as little as possible. This is > > also the type that's being used by consumers of this API, as it was > > documented in chflags(2) since forever. Also, as I already mentioned, > > strtofflags(3) and fflagstostr(3) uses this type too. >=20 > When changing an API, it is best to change it in the correct direction. I don't think we can change strtofflags(3) and fflagstostr(3) API in an non-disruptive way. Because of how chflags(2) and fchflags(2) were documented for so long and how their prototypes where defined in sys/stat.h I'm sure most applications assume they take u_long as flags. So when choosing between those two options (u_int vs. u_long) making it consistent with what applications expect is more important. For me the main goal was to make chflags(2), fchflags(2), lchflags(2) and chflagsat(2) to use the same type for the flags argument, so which tyoe exactly is secondary to me, but I still believe u_long is better (less risky) choice. > > Using u_long for chflags() prototypes in sys/stat.h will only work, > > because of this: > > > > #if !defined(_KERNEL) && __BSD_VISIBLE > > /* > > * XXX We get miscellaneous namespace pollution with this. > > */ > > #include > > #endif > > > > As sys/time.h will include sys/types.h, eventhough sys/stat.h is trying > > to avoid that at the begining. >=20 > I wrote the comment. mike@(gone) fixed the prototypes for *chflags() > so that they don't depend on the namespace pollution. But sys/time.h > still has massive namespace pollution with many other dependences on > the pollution in sys/types.h. >=20 > Of coarse the header must not use the polluting spelling, but the > implementation can use any spelling it wants. >=20 > Actually the header should use the flags type __fflags_t. That is > __uint32_t. This is currently unusuable since the prototypes are > incompatible with it. Changing the prototypes to it would fix them > in the way that I want. Fixed-width types in APIs are design errors, > but we don't worry about that for mode_t, uid_t, ... 32-bit fixed > width types cause fewer problems than most since vax is the only > supported arch so ints are always 32 bits. >=20 > In glibc-2.6, chflags() takes type int for hurd and the default > chflags() (a stub that returns ENOSYS) also takes int. So in ~20 years > when POSIX gets around to standardizing this, it would have to use a > typedefed type like fflags_t, and to support the FreeBSD mistakes it > would need different types for struct stat and the prototypes. >=20 > In linux-2.6.10, file flags are set by ioctl(). ioctl() in linux has > almost the same prototype as in BSD, so the arg type is unsigned long. > glibc-2.6 doesn't have any special support for this ioctl, and the > flags bits depend on the fs for both their name and their number, so > file flags are or were even harder to use in Linux than in FreeBSD, > and further from being standardizable. glibc-2.6 has an fs-independent > bit in mount.h, with a warning that only newer systems support it. > linux-2.6.10 is too old to support it. I you feel strong about using u_int for flags, I'm not oppose to you changing it, as long as you change it for all chflags syscalls:) --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --0IvGJv3f9h+YhkrH Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlFMDVYACgkQForvXbEpPzRJnACeLWV6pQ96EpkTABiHY8UOYMP+ AoUAoOCKM/GhDSrNg4WlMvNQB2HESqLo =sWzI -----END PGP SIGNATURE----- --0IvGJv3f9h+YhkrH-- From owner-freebsd-arch@FreeBSD.ORG Fri Mar 22 09:41:06 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 28D7C8E3 for ; Fri, 22 Mar 2013 09:41:06 +0000 (UTC) (envelope-from dkandula@gmail.com) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) by mx1.freebsd.org (Postfix) with ESMTP id C235335E for ; Fri, 22 Mar 2013 09:41:05 +0000 (UTC) Received: by mail-wi0-f170.google.com with SMTP id hm11so8273067wib.1 for ; Fri, 22 Mar 2013 02:41:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=sIcf+ML8ba+OjXDtfo9I+heByFfVgb6ChOHBUllHzbs=; b=dVIi0/F8AuLboxxTM4OPB9u8NjFlZYE9d4wbca4PUN+vup5Rl42GlRE+7/Ysz4ONNS FfFyqIQxKB1i/q/d2wB3Mp5C+LV34n/iRB/JQQ7KXCtF+x/99Nv1DiZmiACSh43Xcx7X 9/kN+XUI6hgFREnmBsaaVE4erOeo6ZHjifKpNG9DwDl6e15em0BcE6rB0AU0LPWvVOWi Cu+BZbnv69scUa1IwexTO/5YmckSxFaCoBjWLt56aTGkE9V7JziK2glvjJIv2aSRaYql luFKSXz0OhWJ1sI7CV2B9op+V2ZyhSGm0YhMn94uiVPkMkhSvkdXXqDwtenjhhZrwopN T+WQ== MIME-Version: 1.0 X-Received: by 10.180.13.197 with SMTP id j5mr1693302wic.21.1363945264998; Fri, 22 Mar 2013 02:41:04 -0700 (PDT) Received: by 10.194.37.167 with HTTP; Fri, 22 Mar 2013 02:41:04 -0700 (PDT) Date: Fri, 22 Mar 2013 15:11:04 +0530 Message-ID: Subject: Fields tf_addr and tf_err in struct trapframe. From: Dheeraj Kandula To: freebsd-arch@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 09:41:06 -0000 Hey All, Can anyone share what do the two fields "tf_addr" and "tf_err" represent in the structure trapframe for AMD64 processor. I need the info to debug a bug. Dheeraj From owner-freebsd-arch@FreeBSD.ORG Fri Mar 22 12:08:51 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1A01BB14 for ; Fri, 22 Mar 2013 12:08:51 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 8795F217 for ; Fri, 22 Mar 2013 12:08:50 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r2MC8luM017074; Fri, 22 Mar 2013 14:08:47 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.0 kib.kiev.ua r2MC8luM017074 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r2MC8lYL017073; Fri, 22 Mar 2013 14:08:47 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 22 Mar 2013 14:08:47 +0200 From: Konstantin Belousov To: Dheeraj Kandula Subject: Re: Fields tf_addr and tf_err in struct trapframe. Message-ID: <20130322120847.GN3794@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="INL6U/dpJVbCQxtr" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 12:08:51 -0000 --INL6U/dpJVbCQxtr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Mar 22, 2013 at 03:11:04PM +0530, Dheeraj Kandula wrote: > Hey All, > Can anyone share what do the two fields "tf_addr" and "tf_err" > represent in the structure trapframe for AMD64 processor. I need the info > to debug a bug. tf_err comes from the CPU, the value is pushed by the processor when entering the trap handler. See the Intel Architecture Software Development Manual for the description of the exceptions, where you also find the specification of the error code format. It is almost the same for all exceptions, except page fault. tf_addr is used to pass the %cr2 value (the faulting address) from the page fault assembly trampoline to the C exception handler code. Otherwise, it is initialized to 0 by the trampolines for other exceptions. --INL6U/dpJVbCQxtr Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRTEnOAAoJEJDCuSvBvK1BaY4P/ApQJQaz5dI50xRTZ99WWh7d X/5OgWhMAUaUq5U6O2wNkabZ0+85kkNzL4L18YOLxJ8B1JrAcuUNZQ+t16TxcQZf Rn8FuUPqPpVR7EQpXMNQ8m9Kj4K5SJDwUmVyY2D6AOwf5is+zYZ4i1kzUWA/wVVe /Q658sJBdf+o4PlIj5MLWkOsynaLnebKXPzG3b7OwwMYcmVdovDLUR8npxk5idYQ Fd+eQZiHCZXFyPuUyCClT7Ni0EKcQ8ZBZXOOzM0+LacNcen4BdJQK9DHSNbsJDC+ lBbRSEuXTeCaoF4nsadiFe3zU+ctrfhHuSg0K/eSWPv9beCnVeP6AOyBd6LAOHI8 oQ9FT832HoTtrIlIRLCZlED3J1wf4W1FC9UHymfMn7prN4Rv5LlIjCFTfGNgO/5C EldOQyBRHJDiywW9kDbjOmOm0eflP14+CD+PyDWdnUV798RyGZ49VMm70h4x2490 xbCwSfACEzDkFSMVcc4UjsFyXl9l4YxH+ELewJOe5ROle8fT3o6nN0AFTBzpaCwm VTnA7pQtE1P7DW50gSoJSk0oyVGR920IPABuKiqZb6tDrVlu4cwKEPAHXkIwE2wQ eoWOBsb/IY2f2qdCS4275FpMGT69vvVVA6UL8cWnBomZf8qkYTsAzR1/h4VyrabY +Xv4eIZGuBc1Xi9eST69 =uymp -----END PGP SIGNATURE----- --INL6U/dpJVbCQxtr-- From owner-freebsd-arch@FreeBSD.ORG Fri Mar 22 22:28:57 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B738E5AE for ; Fri, 22 Mar 2013 22:28:57 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 3141D14B for ; Fri, 22 Mar 2013 22:28:56 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r2MMSnDH036044; Sat, 23 Mar 2013 00:28:49 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.0 kib.kiev.ua r2MMSnDH036044 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r2MMSlFT036043; Sat, 23 Mar 2013 00:28:47 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 23 Mar 2013 00:28:47 +0200 From: Konstantin Belousov To: Gleb Kurtsou Subject: Re: Increase the mount path to MAXPATHLEN? Message-ID: <20130322222847.GY3794@kib.kiev.ua> References: <20130319201145.GA19260@ambrisko.com> <20130320102116.GA3794@kib.kiev.ua> <20130321034340.GA1120@reks> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KTQgUyhRQoRwtLfu" Content-Disposition: inline In-Reply-To: <20130321034340.GA1120@reks> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 22:28:57 -0000 --KTQgUyhRQoRwtLfu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 20, 2013 at 08:43:40PM -0700, Gleb Kurtsou wrote: > On (20/03/2013 12:21), Konstantin Belousov wrote: > > On Tue, Mar 19, 2013 at 01:11:45PM -0700, Doug Ambrisko wrote: > > > I have a patch at: > > > http://people.freebsd.org/~ambrisko/statf.patch > > > that people can glance at. If this approach is the right way to go > > > then I update it for the latest -current and update it. > >=20 > > No, I do not think this is the right approach. > > You are breaking the ABI in the backward-incompatible way. > >=20 > > What should be done is versioning the fstatfs(2) and other related > > symbols from libc. Please look at the lib/libc/include/compat.h > > and its use for upgrading the syscalls ABI. >=20 > MNAMELEN switch to 1024 was implemented during GSoc 2011. > https://github.com/glk/freebsd-ino64/commit/f2b990cf8861bb72d4477b39426cb= e33f95ffcdf >=20 > freebsd-ino64 repo should contain most recent code, I'll double check > during weekend. It also contains patch to change dev_t to 64 bit. >=20 > https://github.com/glk/freebsd-ino64/commits/projects/ino64 >=20 > Konstantin, do you think it's worth pushing ino64 into CURRENT > considering 10.0 is approaching? The only unresolved issue I can recall > is ABI breakage in audit syscalls, providing compat shims for them > wasn't straightforward due to complex structure. Yes, I do think that ino_t should be finally fixed. Also, please do commit the ABI checking tool to svn. >=20 > Unfortunately I've been swamped at $JOB for a while now and had no time > to clean it up and commit. So if somebody is willing to help please > contact me. What do you need ? What is the estimated time for making this done ? >=20 > > Also, the whole ABI of the system should be inspected for the changes, > > due to possible use of the struct statfs in other structures, or as > > an argument to other functions. > >=20 > > Gleb Kurtsou (gleb@) has a tool which could compare a set of the shlibs > > before and after change for the ABI drift, using the dward debugging > > information. I do not remember where it is stored, definitely worth > > committing somewhere at tools/tools. >=20 > https://github.com/glk/shlib-compat >=20 --KTQgUyhRQoRwtLfu Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRTNsfAAoJEJDCuSvBvK1BHkYQAKXvOOjR4O1U5Sz79ot2Ntfs /x7e6HzepTn2XKnGieOw1jtX74jw6PtoswvP0eXCAPRtBZVOCngDoLeOiK4dr4QV SBFIuUxyvNmx8ChrL/AhI3XUqvNOv01VQ5r6axZoDQMPWQbbSPO5NidV7DScsa4m nHs+ZBndUEuUIeImCR25hIKNIecbD5kWLJawMOArdRF2j/Iq8LbwLPu/nVAqURoE +8A1jcZaLJ4lJLLgOu1h2wlUJPhY/Dds0Q2xBvip+20MezIBjmRXtrS4DSvOXSu0 14RhXQ3zxRC8IBW//+gjchviITbC4YRzh3ICO/rbiZqbzalqHBc5yRbNztJ+IlRh VYFe7BbOGwlweEp1JGTnrjPkOblagGPwR3NySlCduDJMzsjwHiswJ9wn1XH4Vi+6 ZiBANKz2b/XxQs/7ezchaQ46dorInif9IcV8iKNK0HYxG8nFE5KRFUXVkT1EcBls kGepg6Ygz+0imtN2UxPUpuDqqzvu3a41yaDVE7spKsBTbg5kV2oHAfF76B/wieYw bCfjuAPG44GeswceCVeBYXTPtsMgyDqxUabXH39gzGtSOIFUWwoAwppR2QPnFHzq qjGRvTnZJ9flfRN/utzSQaryQa95FXAz0KcAlF745PkdLobL47KGtE0RXCUkW6Ax zc6DU8/spK+S1lwq+sUx =bm8H -----END PGP SIGNATURE----- --KTQgUyhRQoRwtLfu-- From owner-freebsd-arch@FreeBSD.ORG Sat Mar 23 21:10:21 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2DE6462F for ; Sat, 23 Mar 2013 21:10:21 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 7FBBD877 for ; Sat, 23 Mar 2013 21:10:20 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r2NLA31E082292; Sat, 23 Mar 2013 23:10:03 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.0 kib.kiev.ua r2NLA31E082292 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r2NLA13w082265; Sat, 23 Mar 2013 23:10:01 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 23 Mar 2013 23:10:01 +0200 From: Konstantin Belousov To: arch@freebsd.org Subject: VM_BCACHE_SIZE_MAX on i386 Message-ID: <20130323211001.GN3794@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WzMPPjnFM4J49rOr" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: David Wolfskill X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2013 21:10:21 -0000 --WzMPPjnFM4J49rOr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline The unmapped I/O work allows avoiding the map of the vnode pages into the kernel memory for the UFS mounts, if underlying geoms and disk drivers accept unmapped BIOs. Converting all geom classes and drivers, despite not very hard, is quite big task, which requires a lot of validation on the unusual configurations and rare hardware. I decided to provide the transient remapping for the classes which are not yet converted, which allowed to put the work into HEAD much earlier, if at all. When unmapped BIO is passed through the geom stack and next geom is not marked as accepting unmapped BIO, the KVA space in the so called transient map is allocated and pages are mapped there. On the architectures with ample KVA creating the transient map is not an issue, but it is very delicate on the architectures with the limited KVA, i.e. mostly 32bit architectures. To not distrurb the KVA layout and current balance, I split the space previously allocated to the buffer map, into 90% which are still used by the buffer map, and the rest 10%, dedicated to the transient mapping. The split rationale is that typical load have 9/1 split for the user data/metadata buffers, and almost all user data buffers are unmapped. More precisely, the transient map is sized to 10% of the maximum _theoretical_ allowed buffer map size on the arch. Real buffer map is usually smaller, sized proportionally to the available RAM. The details of the allocation are in the vfs_bio.c:kern_vfs_bio_buffer_alloc(). The function uses maxbcache tunable, initialized from VM_BCACHE_SIZE_MAX by default. But, on i386 !PAE, VM_BCACHE_SIZE_MAX is bigger then the maximally sized buffer cache, on the 4GB RAM machine. The max buffer cache map size is around 110MB, while VM_BCACHE_SIZE_MAX is 200MB. This causes the bio_transient_map oversizing, eating additional 90MB of precious KVA on i386. By itself this +90MB KVA use is not critical, but it starts conflicting with other KVA hogs, like nvidia blob, which seemingly tries to remap the whole aperture (256+ MB) into the KVA. The issue was reported by dwh, and appeared to be quite misterious, since his machine has no useful way to report panics from failed X. The resolution I propose is to change the VM_BCACHE_SIZE_MAX on i386 !PAE case, to make it equal to the exact max size of the buffer cache. Note that maxbcache can be tuned from the loader prompt, so the effect of the change would be only on the i386 machines with tuned buffer cache. Also, the patch doubles the size of the transient map to 1/5 of the max buffer cache. This gives 180 parallel remapped i/os in flight, since I consider the re-caclulated 90 i/os too small even for i386. The patch was tested by dwh, please comment. I intend to commit it in several days. http://people.freebsd.org/~kib/misc/i386_maxbcache.1.patch --WzMPPjnFM4J49rOr Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRThopAAoJEJDCuSvBvK1Bn9IQAJOtpC5GcrcB5HwDJGDCO2nU W9zeiFPAzl1H386Ra4auQ1D2BJzGbr7yJdgwVhAFj+/to8FhxCNhZ/wfA1ClTL9g KnXB7pvjk0tcaCP1xf2S6CPBRW4DpOah3L0mLTnPQaSyNUOps5s66pXPn8WE4/2m eqP9jaIc+YBbto+fPneW91heQ2pnVrfLK8mbo4H+x+tjdmiXBNd4zYjIFOd+tPIq LQ9pkjQqo9CprKoByomCD+ddQ5SMVJSK9S0sb3IcElnW2bhVFpt/NgjhT4YN5yPW 5sQ5YvQ4duZHt0iIORS6vI4ExgGsZ4fWvExIhfY6h05lFzOt2j83Sd0xJFAPQulN jpJZUQKWS8ryZJ/CqSsDovxynSB1pS64in+cMtUbZuOmVSVTUEHE9QgsrsWbPy+t j/WGctT7MfYe9Rz+sNkf8LdVyuElWLm4SakM/VpZDxBJwiXyCEurY4KoZVAgD9Op ALa2foB/ACuvK0zcGUHuJWApHD62AR8+CQRkP0W6h7hT0ZgO4pn2R2VMpT86Ulbd yecg8kbgyBsiNeB3hKbKZkA2yyXaM5obG7//YS46eZTsQ4xolNNAVjAKlYLkf2gN Y5LdbChAifhqK3s+9W79SORTmpXwKo6nIxJFYUWcUJ4YoV9DdZcOFRX3fP4U9xnb ZGppbdLW5Gh0DCa6uOsy =wClS -----END PGP SIGNATURE----- --WzMPPjnFM4J49rOr-- From owner-freebsd-arch@FreeBSD.ORG Sat Mar 23 21:27:52 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7822E8CA for ; Sat, 23 Mar 2013 21:27:52 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (m209-73.dsl.rawbw.com [198.144.209.73]) by mx1.freebsd.org (Postfix) with ESMTP id 3B735966 for ; Sat, 23 Mar 2013 21:27:51 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.6/8.14.6) with ESMTP id r2NLRiqD075156; Sat, 23 Mar 2013 14:27:44 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.6/8.14.6/Submit) id r2NLRh0q075155; Sat, 23 Mar 2013 14:27:43 -0700 (PDT) (envelope-from david) Date: Sat, 23 Mar 2013 14:27:43 -0700 From: David Wolfskill To: Konstantin Belousov Subject: Re: VM_BCACHE_SIZE_MAX on i386 Message-ID: <20130323212743.GN42912@albert.catwhisker.org> References: <20130323211001.GN3794@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="h1Kgj0J7YauQlxie" Content-Disposition: inline In-Reply-To: <20130323211001.GN3794@kib.kiev.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: arch@freebsd.org, David Wolfskill X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2013 21:27:52 -0000 --h1Kgj0J7YauQlxie Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Mar 23, 2013 at 11:10:01PM +0200, Konstantin Belousov wrote: > ... > The resolution I propose is to change the VM_BCACHE_SIZE_MAX on i386 > !PAE case, to make it equal to the exact max size of the buffer cache. > Note that maxbcache can be tuned from the loader prompt, so the effect > of the change would be only on the i386 machines with tuned buffer > cache. >=20 > Also, the patch doubles the size of the transient map to 1/5 of the > max buffer cache. This gives 180 parallel remapped i/os in flight, > since I consider the re-caclulated 90 i/os too small even for i386. >=20 > The patch was tested by dwh, please comment. I intend to commit it in > several days. >=20 > http://people.freebsd.org/~kib/misc/i386_maxbcache.1.patch For those interested, the testing involved (after new kernel built @r248612M with the patch) running X with the nvidia driver while performing a "make -j 4 buildworld kernel ... installworld" while I was doing my usual Friday afternoon work-related "stuff" on the machine (which mostly involved running xterms executing on various remote machines, but displaying on the laptop). Subsequently (as in "this morning"), I did my usual daily update of (head) /usr/src & rebuilt -- again while running X with nvidia (as I normally do). That slice is now running FreeBSD 10.0-CURRENT #846 r248645M/248646: Sat Mar 23 06:24:53 PDT 2013. If I encounter issues, I fully expect to "squawk" about it -- most likely, in current@. That said: no issues since applying the patch. :-) Peace, david (aka dhw@freebsd.org) --=20 David H. Wolfskill david@catwhisker.org Taliban: Evil men with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --h1Kgj0J7YauQlxie Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlFOHk8ACgkQmprOCmdXAD25rQCeIte5SDcGH+sM8+cZHnsfvD4u T1MAnixuBFQvhNVLk57bMz3rqLHIGt6p =3kpN -----END PGP SIGNATURE----- --h1Kgj0J7YauQlxie-- From owner-freebsd-arch@FreeBSD.ORG Sat Mar 23 21:49:08 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 763E7192 for ; Sat, 23 Mar 2013 21:49:08 +0000 (UTC) (envelope-from alan.l.cox@gmail.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 13492B4F for ; Sat, 23 Mar 2013 21:49:07 +0000 (UTC) Received: by mail-ee0-f54.google.com with SMTP id c41so2675365eek.27 for ; Sat, 23 Mar 2013 14:49:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:reply-to:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=XU7XGbObuTAVUBMpDJTCV65JXHeZRJz3xIcEqCkcn08=; b=foG0O9kCJFRSP2YjsVLfwIIkAm9x0xYl31tS4LC+LaGxEk2bifyRmOIy9GYQ0oeEKA dNiin4HcH+2a4KDjMNehABv0R70Acv7JIxRQ+zNGvUKM0qEOo7UAIaEdhpTMRCk4jOkj e1uhysglQdwy8ZaibWN6ncSfeynkyExeoYYYZl78vGkUhWhMLNZGQC58tCTm0ZdZaVD3 FRAROnzR3u1FxKenWfxm+cgD9Fk5Ln9FHCbd9Pj1o6CrApo7HoMI5UbUdwiT1K4ISfCY Z5FjsepFUZcgianubzBh+Hgv4DhLReDfSxKgYYt5ol3WYyHjMQCErxsYybDvKd054JXr zA6g== MIME-Version: 1.0 X-Received: by 10.15.67.134 with SMTP id u6mr17856210eex.6.1364075346942; Sat, 23 Mar 2013 14:49:06 -0700 (PDT) Received: by 10.223.127.134 with HTTP; Sat, 23 Mar 2013 14:49:06 -0700 (PDT) In-Reply-To: <20130323211001.GN3794@kib.kiev.ua> References: <20130323211001.GN3794@kib.kiev.ua> Date: Sat, 23 Mar 2013 16:49:06 -0500 Message-ID: Subject: Re: VM_BCACHE_SIZE_MAX on i386 From: Alan Cox To: Konstantin Belousov Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: arch@freebsd.org, David Wolfskill X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: alc@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2013 21:49:08 -0000 On Sat, Mar 23, 2013 at 4:10 PM, Konstantin Belousov wrote: > The unmapped I/O work allows avoiding the map of the vnode pages into > the kernel memory for the UFS mounts, if underlying geoms and disk > drivers accept unmapped BIOs. Converting all geom classes and > drivers, despite not very hard, is quite big task, which requires a > lot of validation on the unusual configurations and rare hardware. I > decided to provide the transient remapping for the classes which are > not yet converted, which allowed to put the work into HEAD much > earlier, if at all. > > When unmapped BIO is passed through the geom stack and next geom is > not marked as accepting unmapped BIO, the KVA space in the so called > transient map is allocated and pages are mapped there. On the > architectures with ample KVA creating the transient map is not an > issue, but it is very delicate on the architectures with the limited > KVA, i.e. mostly 32bit architectures. > > To not distrurb the KVA layout and current balance, I split the space > previously allocated to the buffer map, into 90% which are still used > by the buffer map, and the rest 10%, dedicated to the transient > mapping. The split rationale is that typical load have 9/1 split for > the user data/metadata buffers, and almost all user data buffers are > unmapped. > > More precisely, the transient map is sized to 10% of the maximum > _theoretical_ allowed buffer map size on the arch. Real buffer map is > usually smaller, sized proportionally to the available RAM. The > details of the allocation are in the > vfs_bio.c:kern_vfs_bio_buffer_alloc(). The function uses maxbcache > tunable, initialized from VM_BCACHE_SIZE_MAX by default. > > But, on i386 !PAE, VM_BCACHE_SIZE_MAX is bigger then the maximally > sized buffer cache, on the 4GB RAM machine. The max buffer cache map > size is around 110MB, while VM_BCACHE_SIZE_MAX is 200MB. This causes > the bio_transient_map oversizing, eating additional 90MB of precious > KVA on i386. > > The additional KVA that we had to reserve for the vm_page radix tree nodes already got me thinking about VM_BCACHE_SIZE_MAX a couple weeks ago. With the extra KVA pressure that is inherent to PAE, e.g., a larger vm_page struct, we really can't afford to allow the buffer map KVA allocation to grow much beyond what it would be for a 4GB machine anyway. Moreover, your work makes the size of the buffer map less important, because it will see decreasing use as drivers are converted to allow unmapped I/O. So, I would encourage you to simply use the same cap based on a 4 GB machine for both PAE and !PAE. > By itself this +90MB KVA use is not critical, but it starts > conflicting with other KVA hogs, like nvidia blob, which seemingly > tries to remap the whole aperture (256+ MB) into the KVA. The issue > was reported by dwh, and appeared to be quite misterious, since his > machine has no useful way to report panics from failed X. > > The resolution I propose is to change the VM_BCACHE_SIZE_MAX on i386 > !PAE case, to make it equal to the exact max size of the buffer cache. > Note that maxbcache can be tuned from the loader prompt, so the effect > of the change would be only on the i386 machines with tuned buffer > cache. > > Also, the patch doubles the size of the transient map to 1/5 of the > max buffer cache. This gives 180 parallel remapped i/os in flight, > since I consider the re-caclulated 90 i/os too small even for i386. > > The patch was tested by dwh, please comment. I intend to commit it in > several days. > > http://people.freebsd.org/~kib/misc/i386_maxbcache.1.patch > > From owner-freebsd-arch@FreeBSD.ORG Sat Mar 23 22:10:55 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C04077BD; Sat, 23 Mar 2013 22:10:55 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 5389BD19; Sat, 23 Mar 2013 22:10:55 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r2NMAdu3094210; Sun, 24 Mar 2013 00:10:39 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.0 kib.kiev.ua r2NMAdu3094210 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r2NMAdN4094209; Sun, 24 Mar 2013 00:10:39 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 24 Mar 2013 00:10:39 +0200 From: Konstantin Belousov To: alc@freebsd.org Subject: Re: VM_BCACHE_SIZE_MAX on i386 Message-ID: <20130323221039.GO3794@kib.kiev.ua> References: <20130323211001.GN3794@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="f6rhCtP010UFPtiN" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: arch@freebsd.org, David Wolfskill X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2013 22:10:55 -0000 --f6rhCtP010UFPtiN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sat, Mar 23, 2013 at 04:49:06PM -0500, Alan Cox wrote: > The additional KVA that we had to reserve for the vm_page radix tree nodes > already got me thinking about VM_BCACHE_SIZE_MAX a couple weeks ago. With > the extra KVA pressure that is inherent to PAE, e.g., a larger vm_page > struct, we really can't afford to allow the buffer map KVA allocation to > grow much beyond what it would be for a 4GB machine anyway. Moreover, your > work makes the size of the buffer map less important, because it will see > decreasing use as drivers are converted to allow unmapped I/O. So, I would > encourage you to simply use the same cap based on a 4 GB machine for both > PAE and !PAE. I did not checked it, but isn't default PAE config splits user/kernel on the 2GB boundary ? This makes the KVA pressure on PAE less severe, but user mode should be not very happy. Currently, the number of the regular buffer headers allocated is equal to the size of the buffer map / BKVASIZE still. This could be changed now, I believe that Peter' testing fixed most of the bugs in the handling of the maxbufspace. I was too coward to make this change together with the rest of the work. But it could indeed be useful, since buffer map is used only by the metadata buffers for UFS. I did changed VM_BCACHE_SIZE_MAX as you suggested, thanks. http://people.freebsd.org/~kib/misc/i386_maxbcache.2.patch --f6rhCtP010UFPtiN Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRTiheAAoJEJDCuSvBvK1BCDMP/3GQV+rClMKxGms5CLMlXfPW 89UwFQOK896bWe8h26q4Y+OXFiJB+no6L+qf8jPX0N5PK9tyLRwgupB/v/bV4tm1 nUij9sOwxtI2i2ULLwI4QrC/onD9BjiALBxjXLlRQcVUajSgereDK0JCfyfpLDgc qR2lZ/X5GHACRlyzb9/Gw1WkztmBYFS5uzbKtY97jAf0nui/T0XboBE4rFrf1NiE f6kbkYamUkiOz8fLmEERgzHUsU7/JKeuBDuvbDkAd2ZY3G6rE+i3paT7FO1Fyi6g u5P/1pw/9tQ9UBCE5YzDtgVDmclz4oebWd8/PXCr0y3eJZ0m8cyqV45JcYXkkULe 3c9MobHDHtJBQgijWNghXBNswhm8uSuv0pAfOt7mLxS7oPKpEkCycBzNP2DohafO MkLD5noqlKmAtRsp8t7PdZ8e22ziuoQbRCJd8Anrah91ppEYG0+wa6m4MdlvJpsm hHEIJXk+zyEYDXhWawiI0XCHXRzMmGdvq1UylomRxoOVeyGk82fPKFvWBWZHWn8n bvYGqWrHaQ32tLvIeAlE1E+xY5o0yHVeAngqC1Mnp77ADQ0YzT14g2pOIFYDUo02 hlHEDJOuoX9xafl1JowQOGksyC7en4qmK0umBR/4J70RiIgFGrwjNhT9uWt8j06U nOvUcPzX7qUc93OVb1hm =P9+l -----END PGP SIGNATURE----- --f6rhCtP010UFPtiN-- From owner-freebsd-arch@FreeBSD.ORG Sat Mar 23 23:45:10 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7B9D3A41 for ; Sat, 23 Mar 2013 23:45:10 +0000 (UTC) (envelope-from alan.l.cox@gmail.com) Received: from mail-ee0-f50.google.com (mail-ee0-f50.google.com [74.125.83.50]) by mx1.freebsd.org (Postfix) with ESMTP id 175D1157 for ; Sat, 23 Mar 2013 23:45:09 +0000 (UTC) Received: by mail-ee0-f50.google.com with SMTP id d4so369131eek.37 for ; Sat, 23 Mar 2013 16:45:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:reply-to:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=SfigaqGLgyRANrQkgBcOIjDRq3BD2IsexzrNn7+DPYE=; b=GPTLCLCRK2wbJ6+9PkBBhFmfOLoiqdYAbtD25W3o8DC+USqBy/aNVXkW0NturjErwb sY2ki4m6GH/DLA5uzvsDCr5qn1YII8bqaLTrgH5aP3uxDFxyQKZMRrQnvqXnMlvFEJXv rOkwp/bQDRl46I+h17fqk7jq9ih3+juzWygqs5PZWl18oTdkrGfEAgjuSp2SbqCTaxR4 K4HAurQ6Pdh6Ml1UyJ5xTIIPtdNUlxJx9tQXFCHE0DzJiSHx7v0UNlKX/ggK5RCIrJeL bjHQZb2N04bUoiHKg9FisXIUokveY0P5xJfSx2Xy2GCUMMkvBjIxPmkry9/MScANdLwo tuhQ== MIME-Version: 1.0 X-Received: by 10.14.194.198 with SMTP id m46mr18503591een.8.1364082303075; Sat, 23 Mar 2013 16:45:03 -0700 (PDT) Received: by 10.223.127.134 with HTTP; Sat, 23 Mar 2013 16:45:02 -0700 (PDT) In-Reply-To: <20130323221039.GO3794@kib.kiev.ua> References: <20130323211001.GN3794@kib.kiev.ua> <20130323221039.GO3794@kib.kiev.ua> Date: Sat, 23 Mar 2013 18:45:02 -0500 Message-ID: Subject: Re: VM_BCACHE_SIZE_MAX on i386 From: Alan Cox To: Konstantin Belousov Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: arch@freebsd.org, David Wolfskill X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: alc@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2013 23:45:10 -0000 On Sat, Mar 23, 2013 at 5:10 PM, Konstantin Belousov wrote: > On Sat, Mar 23, 2013 at 04:49:06PM -0500, Alan Cox wrote: > > The additional KVA that we had to reserve for the vm_page radix tree > nodes > > already got me thinking about VM_BCACHE_SIZE_MAX a couple weeks ago. > With > > the extra KVA pressure that is inherent to PAE, e.g., a larger vm_page > > struct, we really can't afford to allow the buffer map KVA allocation to > > grow much beyond what it would be for a 4GB machine anyway. Moreover, > your > > work makes the size of the buffer map less important, because it will see > > decreasing use as drivers are converted to allow unmapped I/O. So, I > would > > encourage you to simply use the same cap based on a 4 GB machine for both > > PAE and !PAE. > > I did not checked it, but isn't default PAE config splits user/kernel > on the 2GB boundary ? This makes the KVA pressure on PAE less severe, > but user mode should be not very happy. > > No, the PAE split between user/kernel is the same as !PAE. The PAE config is deceptive because it takes twice as many page table pages to get the same 1 GB of KVA. > Currently, the number of the regular buffer headers allocated is equal > to the size of the buffer map / BKVASIZE still. This could be changed > now, I believe that Peter' testing fixed most of the bugs in the > handling of the maxbufspace. I was too coward to make this change > together with the rest of the work. But it could indeed be useful, since > buffer map is used only by the metadata buffers for UFS. > > I did changed VM_BCACHE_SIZE_MAX as you suggested, thanks. > > http://people.freebsd.org/~kib/misc/i386_maxbcache.2.patch >