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--