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