From owner-freebsd-arch@FreeBSD.ORG Sun Feb 24 06:06: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 B9A33693 for ; Sun, 24 Feb 2013 06:06:00 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by mx1.freebsd.org (Postfix) with ESMTP id 59E661665 for ; Sun, 24 Feb 2013 06:06:00 +0000 (UTC) Received: from mailout-de.gmx.net ([10.1.76.1]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0MBYz2-1U2JBx1Rqg-00AUD2 for ; Sun, 24 Feb 2013 07:05:59 +0100 Received: (qmail invoked by alias); 24 Feb 2013 06:05:59 -0000 Received: from p5B132BDD.dip.t-dialin.net (EHLO rotluchs.lokal) [91.19.43.221] by mail.gmx.net (mp001) with SMTP; 24 Feb 2013 07:05:59 +0100 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX19Fs7kJkilF/2zVKTg79YSo4pOtjpp1x8Ymf5WEQz kR8JlyNNR3ZiId Message-ID: <5129ADC5.5040306@gmx.de> Date: Sun, 24 Feb 2013 07:05:57 +0100 From: Christoph Mallon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130222 Thunderbird/17.0.3 MIME-Version: 1.0 To: Pawel Jakub Dawidek Subject: Re: Large Capsicum patch for review. References: <20130213025547.GA2025@garage.freebsd.pl> <20130213230221.GB1375@garage.freebsd.pl> <20130223221116.GR1377@garage.freebsd.pl> In-Reply-To: <20130223221116.GR1377@garage.freebsd.pl> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 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, 24 Feb 2013 06:06:00 -0000 Hi. On 23.02.2013 23:11, Pawel Jakub Dawidek wrote: > On Thu, Feb 14, 2013 at 12:02:22AM +0100, Pawel Jakub Dawidek wrote: >> I'd like to commit this patch: >> >> http://people.freebsd.org/~pjd/patches/capkern.diff > > The patch was updated after the following changes and is available at > the link above: I was not able to apply this patch cleanly and had to fudge with the diff: - Two diff headers (contrib/openbsm/etc/audit_event and lib/libc/gen/Makefile.inc) have an extra space after --- and +++, which is recognized as part of the filename. Was this patch manually altered? - Two diffs (lib/libc/sys/cap_new.2 and sys/kern/uipc_mqueue.c) contain unexpanded $FreeBSD$ tags. I also had to guess, that the patch is to be applied onto r247201. I placed a cleaned up patch at http://tron.homeunix.org/zeug/FreeBSD/capsicum/0001-Capsicum-update.patch. This is a really big patch bomb changing lots of unrelated things. Do you have smaller, more managable diffs for easier review? I started reading the patch and found some minor glitches, e.g. mode in cap_sandboxed() should be u_int, not int. I will report more later. Christoph From owner-freebsd-arch@FreeBSD.ORG Sun Feb 24 15:07: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 96F17B35 for ; Sun, 24 Feb 2013 15:07:22 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by mx1.freebsd.org (Postfix) with ESMTP id BDED763D for ; Sun, 24 Feb 2013 15:07:21 +0000 (UTC) Received: from mailout-de.gmx.net ([10.1.76.19]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0LpRRz-1Uokoo03Ij-00f7x6 for ; Sun, 24 Feb 2013 16:07:15 +0100 Received: (qmail invoked by alias); 24 Feb 2013 15:07:13 -0000 Received: from p5B13215E.dip.t-dialin.net (EHLO rotluchs.lokal) [91.19.33.94] by mail.gmx.net (mp019) with SMTP; 24 Feb 2013 16:07:13 +0100 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX184jUNhtPE4TTvh5tpgcAPFCLPthbBJqMVTotM6Bt zV2I9Xi6se3w8j Message-ID: <512A2CA0.2050509@gmx.de> Date: Sun, 24 Feb 2013 16:07:12 +0100 From: Christoph Mallon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130222 Thunderbird/17.0.3 MIME-Version: 1.0 To: Pawel Jakub Dawidek Subject: Re: Large Capsicum patch for review. References: <20130213025547.GA2025@garage.freebsd.pl> <20130213230221.GB1375@garage.freebsd.pl> <20130223221116.GR1377@garage.freebsd.pl> <5129ADC5.5040306@gmx.de> In-Reply-To: <5129ADC5.5040306@gmx.de> Content-Type: multipart/mixed; boundary="------------060105070608040709090402" X-Y-GMX-Trusted: 0 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, 24 Feb 2013 15:07:22 -0000 This is a multi-part message in MIME format. --------------060105070608040709090402 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 24.02.2013 07:05, Christoph Mallon wrote: > I started reading the patch and found some minor glitches, e.g. mode in cap_sandboxed() should be u_int, not int. > I will report more later. I placed several patches with suggested changes at http://tron.homeunix.org/zeug/FreeBSD/capsicum/ (I also attached them). Please have a look at them. I also have some comments: - A bitmask for cap_rights_limit() seems limited. There are only six bits left unused. Maybe a more general mechanism should be used. - I think that CAP_SEND, CAP_RECV, CAP_FCHMODAT, CAP_FCHOWNAT, CAP_FSTATAT and CAP_FUTIMESAT are pointless aliases, which provide no benefit, but rather might cause confusion, whether there is a difference between e.g. CAP_WRITE and CAP_SEND. - Why did you choose INT_MAX to represent "all capabilities"? The data type used is ssize_t, so SSIZE_MAX seems more logical. Further, there are several places where size_t and ssize_t come into contact, which need careful tests and casts to get right. Maybe it is better to always use size_t and represent "all capabilities" with SIZE_T_MAX or (size_t)-1 (which is guaranteed by C to be the maximal value). - Is it correct, that fdp seems to be not locked in fp_getfvp()? Otherweise, fget_locked() could be used instead of the manual check. - I could not verify many changes, e.g. changed requested permissions, because this is just a big diff with no information about the intention of the changes. A series of smaller diffs with commit logs to state their intent would be really useful for reviewing. Christoph --------------060105070608040709090402 Content-Type: text/plain; charset=UTF-8; name="0002-Use-the-correct-type-for-the-parameter-of-cap_getmod.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename*0="0002-Use-the-correct-type-for-the-parameter-of-cap_getmod.pa"; filename*1="tch" RnJvbSA3ZjE4MTg2YzQ1MWMyMzViY2MzZGJmMmUyNWY2NTYxM2UxY2U3ZjE2IE1vbiBTZXAg MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBDaHJpc3RvcGggTWFsbG9uIDxjaHJpc3RvcGgubWFs bG9uQGdteC5kZT4KRGF0ZTogU3VuLCAyNCBGZWIgMjAxMyAxMzowMTowMCArMDEwMApTdWJq ZWN0OiBbUEFUQ0ggMDIvMjRdIFVzZSB0aGUgY29ycmVjdCB0eXBlIGZvciB0aGUgcGFyYW1l dGVyIG9mCiBjYXBfZ2V0bW9kZSgpLgoKLS0tCiBsaWIvbGliYy9nZW4vY2FwX3NhbmRib3hl ZC5jIHwgMiArLQogMSBmaWxlIGNoYW5nZWQsIDEgaW5zZXJ0aW9uKCspLCAxIGRlbGV0aW9u KC0pCgpkaWZmIC0tZ2l0IGEvbGliL2xpYmMvZ2VuL2NhcF9zYW5kYm94ZWQuYyBiL2xpYi9s aWJjL2dlbi9jYXBfc2FuZGJveGVkLmMKaW5kZXggOTVlNWIyMy4uNTc0M2YyYSAxMDA2NDQK LS0tIGEvbGliL2xpYmMvZ2VuL2NhcF9zYW5kYm94ZWQuYworKysgYi9saWIvbGliYy9nZW4v Y2FwX3NhbmRib3hlZC5jCkBAIC0zOSw3ICszOSw3IEBAIF9fRkJTRElEKCIkRnJlZUJTRCQi KTsKIGJvb2wKIGNhcF9zYW5kYm94ZWQodm9pZCkKIHsKLQlpbnQgbW9kZTsKKwl1X2ludCBt b2RlOwogCiAJaWYgKGNhcF9nZXRtb2RlKCZtb2RlKSA9PSAtMSkgewogCQlhc3NlcnQoZXJy bm8gPT0gRU5PU1lTKTsKLS0gCjEuOC4xLjMKCg== --------------060105070608040709090402 Content-Type: text/plain; charset=UTF-8; name="0003-Use-cheaper-0-tests.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="0003-Use-cheaper-0-tests.patch" RnJvbSA3YWQwOWEwY2YwY2ViOTgyODE3MTEzM2UzMmY3MTQ4ZmZkZTYyZDk3IE1vbiBTZXAg MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBDaHJpc3RvcGggTWFsbG9uIDxjaHJpc3RvcGgubWFs bG9uQGdteC5kZT4KRGF0ZTogU3VuLCAyNCBGZWIgMjAxMyAxMzowMzowMyArMDEwMApTdWJq ZWN0OiBbUEFUQ0ggMDMvMjRdIFVzZSBjaGVhcGVyICE9IDAgdGVzdHMuCgotLS0KIGxpYi9s aWJjL2dlbi9jYXBfc2FuZGJveGVkLmMgfCA0ICsrLS0KIDEgZmlsZSBjaGFuZ2VkLCAyIGlu c2VydGlvbnMoKyksIDIgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvbGliL2xpYmMvZ2Vu L2NhcF9zYW5kYm94ZWQuYyBiL2xpYi9saWJjL2dlbi9jYXBfc2FuZGJveGVkLmMKaW5kZXgg NTc0M2YyYS4uZjA5YjU5MCAxMDA2NDQKLS0tIGEvbGliL2xpYmMvZ2VuL2NhcF9zYW5kYm94 ZWQuYworKysgYi9saWIvbGliYy9nZW4vY2FwX3NhbmRib3hlZC5jCkBAIC00MSwxMCArNDEs MTAgQEAgY2FwX3NhbmRib3hlZCh2b2lkKQogewogCXVfaW50IG1vZGU7CiAKLQlpZiAoY2Fw X2dldG1vZGUoJm1vZGUpID09IC0xKSB7CisJaWYgKGNhcF9nZXRtb2RlKCZtb2RlKSAhPSAw KSB7CiAJCWFzc2VydChlcnJubyA9PSBFTk9TWVMpOwogCQlyZXR1cm4gKGZhbHNlKTsKIAl9 CiAJYXNzZXJ0KG1vZGUgPT0gMCB8fCBtb2RlID09IDEpOwotCXJldHVybiAobW9kZSA9PSAx KTsKKwlyZXR1cm4gKG1vZGUgIT0gMCk7CiB9Ci0tIAoxLjguMS4zCgo= --------------060105070608040709090402 Content-Type: text/plain; charset=UTF-8; name="0004-Add-cap_sandboxed-to-Symbol.map.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="0004-Add-cap_sandboxed-to-Symbol.map.patch" RnJvbSBhZTZhYzhiODIzNzRlODNkY2MyYmRhN2RkNmUxN2RhNWQ2NWQ5ZWFlIE1vbiBTZXAg MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBDaHJpc3RvcGggTWFsbG9uIDxjaHJpc3RvcGgubWFs bG9uQGdteC5kZT4KRGF0ZTogU3VuLCAyNCBGZWIgMjAxMyAxMzowMzoyNCArMDEwMApTdWJq ZWN0OiBbUEFUQ0ggMDQvMjRdIEFkZCBjYXBfc2FuZGJveGVkIHRvIFN5bWJvbC5tYXAuCgot LS0KIGxpYi9saWJjL3N5cy9TeW1ib2wubWFwIHwgMSArCiAxIGZpbGUgY2hhbmdlZCwgMSBp bnNlcnRpb24oKykKCmRpZmYgLS1naXQgYS9saWIvbGliYy9zeXMvU3ltYm9sLm1hcCBiL2xp Yi9saWJjL3N5cy9TeW1ib2wubWFwCmluZGV4IDM3NmFjZTAuLjc3MzhlNDYgMTAwNjQ0Ci0t LSBhL2xpYi9saWJjL3N5cy9TeW1ib2wubWFwCisrKyBiL2xpYi9saWJjL3N5cy9TeW1ib2wu bWFwCkBAIC0zODQsNiArMzg0LDcgQEAgRkJTRF8xLjMgewogCWNhcF9pb2N0bHNfbGltaXQ7 CiAJY2FwX3JpZ2h0c19nZXQ7CiAJY2FwX3JpZ2h0c19saW1pdDsKKwljYXBfc2FuZGJveGVk OwogCWNsb2NrX2dldGNwdWNsb2NraWQyOwogCWZmY2xvY2tfZ2V0Y291bnRlcjsKIAlmZmNs b2NrX2dldGVzdGltYXRlOwotLSAKMS44LjEuMwoK --------------060105070608040709090402 Content-Type: text/plain; charset=UTF-8; name="0005-Use-standard-inline-instead-of-the-GNUism-__inline.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename*0="0005-Use-standard-inline-instead-of-the-GNUism-__inline.patc"; filename*1="h" RnJvbSA0ODIyZmFlYzhlYTVjNTNjNjczNzQwZWVlYzBjYjYwNDk2MGFmMzdiIE1vbiBTZXAg MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBDaHJpc3RvcGggTWFsbG9uIDxjaHJpc3RvcGgubWFs bG9uQGdteC5kZT4KRGF0ZTogU3VuLCAyNCBGZWIgMjAxMyAxMzowMzo1OSArMDEwMApTdWJq ZWN0OiBbUEFUQ0ggMDUvMjRdIFVzZSBzdGFuZGFyZCBpbmxpbmUgaW5zdGVhZCBvZiB0aGUg R05VaXNtIF9faW5saW5lLgoKLS0tCiBzeXMva2Vybi9zeXNfY2FwYWJpbGl0eS5jIHwgMiAr LQogMSBmaWxlIGNoYW5nZWQsIDEgaW5zZXJ0aW9uKCspLCAxIGRlbGV0aW9uKC0pCgpkaWZm IC0tZ2l0IGEvc3lzL2tlcm4vc3lzX2NhcGFiaWxpdHkuYyBiL3N5cy9rZXJuL3N5c19jYXBh YmlsaXR5LmMKaW5kZXggOTQxZWE0OS4uMGY0ZWYxMiAxMDA2NDQKLS0tIGEvc3lzL2tlcm4v c3lzX2NhcGFiaWxpdHkuYworKysgYi9zeXMva2Vybi9zeXNfY2FwYWJpbGl0eS5jCkBAIC0x NDQsNyArMTQ0LDcgQEAgc3lzX2NhcF9nZXRtb2RlKHN0cnVjdCB0aHJlYWQgKnRkLCBzdHJ1 Y3QgY2FwX2dldG1vZGVfYXJncyAqdWFwKQogCiBGRUFUVVJFKHNlY3VyaXR5X2NhcGFiaWxp dGllcywgIkNhcHNpY3VtIENhcGFiaWxpdGllcyIpOwogCi1zdGF0aWMgX19pbmxpbmUgaW50 CitzdGF0aWMgaW5saW5lIGludAogX2NhcF9jaGVjayhjYXBfcmlnaHRzX3QgaGF2ZSwgY2Fw X3JpZ2h0c190IG5lZWQsIGVudW0ga3RyX2NhcF9mYWlsX3R5cGUgdHlwZSkKIHsKIAotLSAK MS44LjEuMwoK --------------060105070608040709090402 Content-Type: text/plain; charset=UTF-8; name="0006-Avoid-polluting-the-global-namespace-with-stdbool.h.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename*0="0006-Avoid-polluting-the-global-namespace-with-stdbool.h.pat"; filename*1="ch" RnJvbSAxZDFkZWZkZjdkZDExN2FmYTU2MzMwYzk1OGRhZWFjNWQ1MmJlMDVmIE1vbiBTZXAg MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBDaHJpc3RvcGggTWFsbG9uIDxjaHJpc3RvcGgubWFs bG9uQGdteC5kZT4KRGF0ZTogU3VuLCAyNCBGZWIgMjAxMyAxMzowNDo0MSArMDEwMApTdWJq ZWN0OiBbUEFUQ0ggMDYvMjRdIEF2b2lkIHBvbGx1dGluZyB0aGUgZ2xvYmFsIG5hbWVzcGFj ZSB3aXRoIHN0ZGJvb2wuaC4KCi0tLQogc3lzL3N5cy9jYXBhYmlsaXR5LmggfCAzICstLQog MSBmaWxlIGNoYW5nZWQsIDEgaW5zZXJ0aW9uKCspLCAyIGRlbGV0aW9ucygtKQoKZGlmZiAt LWdpdCBhL3N5cy9zeXMvY2FwYWJpbGl0eS5oIGIvc3lzL3N5cy9jYXBhYmlsaXR5LmgKaW5k ZXggZGY5NWFlNC4uOWVlZDRkMSAxMDA2NDQKLS0tIGEvc3lzL3N5cy9jYXBhYmlsaXR5LmgK KysrIGIvc3lzL3N5cy9jYXBhYmlsaXR5LmgKQEAgLTI1MSw3ICsyNTEsNiBAQCBpbnQJY2Fw X2ZjbnRsX2NoZWNrKHN0cnVjdCBmaWxlZGVzYyAqZmRwLCBpbnQgZmQsIGludCBjbWQpOwog I2Vsc2UgLyogIV9LRVJORUwgKi8KIAogX19CRUdJTl9ERUNMUwotI2luY2x1ZGUgPHN0ZGJv b2wuaD4KIAogLyoKICAqIGNhcF9lbnRlcigpOiBDYXVzZSB0aGUgcHJvY2VzcyB0byBlbnRl ciBjYXBhYmlsaXR5IG1vZGUsIHdoaWNoIHdpbGwKQEAgLTI3MCw3ICsyNjksNyBAQCBpbnQJ Y2FwX2VudGVyKHZvaWQpOwogICogQXJlIHdlIHNhbmRib3hlZCAoaW4gY2FwYWJpbGl0eSBt b2RlKT8KICAqIFRoaXMgaXMgbGliYyB3cmFwcGVyIGFyb3VuZCBjYXBfZ2V0bW9kZSgyKSBz eXN0ZW0gY2FsbC4KICAqLwotYm9vbAljYXBfc2FuZGJveGVkKHZvaWQpOworX0Jvb2wJY2Fw X3NhbmRib3hlZCh2b2lkKTsKIAogLyoKICAqIGNhcF9nZXRtb2RlKCk6IEFyZSB3ZSBpbiBj YXBhYmlsaXR5IG1vZGU/Ci0tIAoxLjguMS4zCgo= --------------060105070608040709090402 Content-Type: text/plain; charset=UTF-8; name="0007-Use-CC-instead-of-hardcoding-gcc.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="0007-Use-CC-instead-of-hardcoding-gcc.patch" RnJvbSA1MTA3YWI5YWVjNjc2NmM5Y2U1Mjg1OTM5NjM3YzU3MzliMmFlZDBjIE1vbiBTZXAg MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBDaHJpc3RvcGggTWFsbG9uIDxjaHJpc3RvcGgubWFs bG9uQGdteC5kZT4KRGF0ZTogU3VuLCAyNCBGZWIgMjAxMyAxMzowNToxOSArMDEwMApTdWJq ZWN0OiBbUEFUQ0ggMDcvMjRdIFVzZSAke0NDfSBpbnN0ZWFkIG9mIGhhcmRjb2RpbmcgZ2Nj LgoKLS0tCiB0b29scy9yZWdyZXNzaW9uL2NhcHNpY3VtL3N5c2NhbGxzL01ha2VmaWxlIHwg MiArLQogMSBmaWxlIGNoYW5nZWQsIDEgaW5zZXJ0aW9uKCspLCAxIGRlbGV0aW9uKC0pCgpk aWZmIC0tZ2l0IGEvdG9vbHMvcmVncmVzc2lvbi9jYXBzaWN1bS9zeXNjYWxscy9NYWtlZmls ZSBiL3Rvb2xzL3JlZ3Jlc3Npb24vY2Fwc2ljdW0vc3lzY2FsbHMvTWFrZWZpbGUKaW5kZXgg Y2IxYjA3Yi4uNWQzNDIyNiAxMDA2NDQKLS0tIGEvdG9vbHMvcmVncmVzc2lvbi9jYXBzaWN1 bS9zeXNjYWxscy9NYWtlZmlsZQorKysgYi90b29scy9yZWdyZXNzaW9uL2NhcHNpY3VtL3N5 c2NhbGxzL01ha2VmaWxlCkBAIC0xNCw3ICsxNCw3IEBAIGFsbDoJJHtTWVNDQUxMU30gJHtT WVNDQUxMUzo9LnR9CiAuZm9yIFNZU0NBTEwgaW4gJHtTWVNDQUxMU30KIAogJHtTWVNDQUxM fToJJHtTWVNDQUxMfS5jIG1pc2MuYwotCWdjYyAke0NGTEFHU30gJHtAfS5jIG1pc2MuYyAt byAkQAorCSR7Q0N9ICR7Q0ZMQUdTfSAke0B9LmMgbWlzYy5jIC1vICRACiAKICR7U1lTQ0FM TH0udDoJJHtTWVNDQUxMfQogCUBwcmludGYgIiMhL2Jpbi9zaFxuXG4lcy8lc1xuIiAkey5D VVJESVJ9ICR7QDoudD19ID4gJEAKLS0gCjEuOC4xLjMKCg== --------------060105070608040709090402 Content-Type: text/plain; charset=UTF-8; name="0008-Use-fget_locked-instead-of-duplicating-it.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="0008-Use-fget_locked-instead-of-duplicating-it.patch" RnJvbSBkMmZlN2E2ZjlkOGUwODk0MzYwMGIxZjVkNmEyODE4YzZjNGFhNzk0IE1vbiBTZXAg MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBDaHJpc3RvcGggTWFsbG9uIDxjaHJpc3RvcGgubWFs bG9uQGdteC5kZT4KRGF0ZTogU3VuLCAyNCBGZWIgMjAxMyAxMzozMTozNyArMDEwMApTdWJq ZWN0OiBbUEFUQ0ggMDgvMjRdIFVzZSBmZ2V0X2xvY2tlZCgpIGluc3RlYWQgb2YgZHVwbGlj YXRpbmcgaXQuCgotLS0KIHN5cy9rZXJuL3VpcGNfdXNycmVxLmMgfCAzICstLQogc3lzL25l dHNtYi9zbWJfZGV2LmMgICB8IDQgKy0tLQogMiBmaWxlcyBjaGFuZ2VkLCAyIGluc2VydGlv bnMoKyksIDUgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvc3lzL2tlcm4vdWlwY191c3Jy ZXEuYyBiL3N5cy9rZXJuL3VpcGNfdXNycmVxLmMKaW5kZXggMTVhMWM4YS4uNTI5ZDJlYiAx MDA2NDQKLS0tIGEvc3lzL2tlcm4vdWlwY191c3JyZXEuYworKysgYi9zeXMva2Vybi91aXBj X3VzcnJlcS5jCkBAIC0xODU4LDggKzE4NTgsNyBAQCB1bnBfaW50ZXJuYWxpemUoc3RydWN0 IG1idWYgKipjb250cm9scCwgc3RydWN0IHRocmVhZCAqdGQpCiAJCQlGSUxFREVTQ19TTE9D SyhmZGVzYyk7CiAJCQlmb3IgKGkgPSAwOyBpIDwgb2xkZmRzOyBpKyspIHsKIAkJCQlmZCA9 ICpmZHArKzsKLQkJCQlpZiAoZmQgPCAwIHx8IGZkID49IGZkZXNjLT5mZF9uZmlsZXMgfHwK LQkJCQkgICAgZmRlc2MtPmZkX29maWxlc1tmZF0uZmRlX2ZpbGUgPT0gTlVMTCkgeworCQkJ CWlmIChmZ2V0X2xvY2tlZChmZHAsIGZkKSA9PSBOVUxMKSB7CiAJCQkJCUZJTEVERVNDX1NV TkxPQ0soZmRlc2MpOwogCQkJCQllcnJvciA9IEVCQURGOwogCQkJCQlnb3RvIG91dDsKZGlm ZiAtLWdpdCBhL3N5cy9uZXRzbWIvc21iX2Rldi5jIGIvc3lzL25ldHNtYi9zbWJfZGV2LmMK aW5kZXggMGNlZTMyNS4uYTA5ZDc0ZCAxMDA2NDQKLS0tIGEvc3lzL25ldHNtYi9zbWJfZGV2 LmMKKysrIGIvc3lzL25ldHNtYi9zbWJfZGV2LmMKQEAgLTM5OSw5ICszOTksNyBAQCBuc21i X2dldGZwKHN0cnVjdCBmaWxlZGVzYyogZmRwLCBpbnQgZmQsIGludCBmbGFnKQogCXN0cnVj dCBmaWxlKiBmcDsKIAogCUZJTEVERVNDX1NMT0NLKGZkcCk7Ci0JaWYgKGZkIDwgMCB8fCBm ZCA+PSBmZHAtPmZkX25maWxlcyB8fAotCSAgICAoZnAgPSBmZHAtPmZkX29maWxlc1tmZF0u ZmRlX2ZpbGUpID09IE5VTEwgfHwKLQkgICAgKGZwLT5mX2ZsYWcgJiBmbGFnKSA9PSAwKSB7 CisJaWYgKChmcCA9IGZnZXRfbG9ja2VkKGZkcCwgZmQpKSA9PSBOVUxMIHx8IChmcC0+Zl9m bGFnICYgZmxhZykgPT0gMCkgewogCQlGSUxFREVTQ19TVU5MT0NLKGZkcCk7CiAJCXJldHVy biAoTlVMTCk7CiAJfQotLSAKMS44LjEuMwoK --------------060105070608040709090402 Content-Type: text/plain; charset=UTF-8; name="0009-Remove-duplicate-checks.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="0009-Remove-duplicate-checks.patch" RnJvbSBjYzJkZTQyZTk0NDgyODk0M2MxN2ZjYmEyYTgyMWJlY2M2MzRiOWE0IE1vbiBTZXAg MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBDaHJpc3RvcGggTWFsbG9uIDxjaHJpc3RvcGgubWFs bG9uQGdteC5kZT4KRGF0ZTogU3VuLCAyNCBGZWIgMjAxMyAxMzozMzo0OSArMDEwMApTdWJq ZWN0OiBbUEFUQ0ggMDkvMjRdIFJlbW92ZSBkdXBsaWNhdGUgY2hlY2tzLgoKZmdldF9sb2Nr ZWQoKSBqdXN0IGJlbG93IGRvZXMgdGhlIHNhbWUgY2hlY2tzLgotLS0KIHN5cy9rZXJuL2tl cm5fZGVzY3JpcC5jIHwgNSAtLS0tLQogMSBmaWxlIGNoYW5nZWQsIDUgZGVsZXRpb25zKC0p CgpkaWZmIC0tZ2l0IGEvc3lzL2tlcm4va2Vybl9kZXNjcmlwLmMgYi9zeXMva2Vybi9rZXJu X2Rlc2NyaXAuYwppbmRleCBiZWQ1ZDhmLi40NzNhYjQwIDEwMDY0NAotLS0gYS9zeXMva2Vy bi9rZXJuX2Rlc2NyaXAuYworKysgYi9zeXMva2Vybi9rZXJuX2Rlc2NyaXAuYwpAQCAtMjQ1 OSwxMSArMjQ1OSw2IEBAIGZnZXR2cF9yaWdodHMoc3RydWN0IHRocmVhZCAqdGQsIGludCBm ZCwgY2FwX3JpZ2h0c190IG5lZWQsCiAJaWYgKHRkID09IE5VTEwgfHwgKGZkcCA9IHRkLT50 ZF9wcm9jLT5wX2ZkKSA9PSBOVUxMKQogCQlyZXR1cm4gKEVCQURGKTsKIAotCUZJTEVERVND X0xPQ0tfQVNTRVJUKGZkcCk7Ci0KLQlpZiAoZmQgPCAwIHx8IGZkID49IGZkcC0+ZmRfbmZp bGVzKQotCQlyZXR1cm4gKEVCQURGKTsKLQogCWZwID0gZmdldF9sb2NrZWQoZmRwLCBmZCk7 CiAJaWYgKGZwID09IE5VTEwgfHwgZnAtPmZfb3BzID09ICZiYWRmaWxlb3BzKQogCQlyZXR1 cm4gKEVCQURGKTsKLS0gCjEuOC4xLjMKCg== --------------060105070608040709090402 Content-Type: text/plain; charset=UTF-8; name="0010-Make-fp_getfvp-static.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="0010-Make-fp_getfvp-static.patch" RnJvbSAyYjlhZGQ3Mzk2YTk0ODVhZGQ2YTQyNDYwNzFjZjA0MWE1MDE2MWQxIE1vbiBTZXAg MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBDaHJpc3RvcGggTWFsbG9uIDxjaHJpc3RvcGgubWFs bG9uQGdteC5kZT4KRGF0ZTogU3VuLCAyNCBGZWIgMjAxMyAxMzozNDo0MyArMDEwMApTdWJq ZWN0OiBbUEFUQ0ggMTAvMjRdIE1ha2UgZnBfZ2V0ZnZwKCkgc3RhdGljLgoKLS0tCiBzeXMv ZnMvbmZzL25mc2Rwb3J0LmggICAgICAgICAgIHwgMiAtLQogc3lzL2ZzL25mc3NlcnZlci9u ZnNfbmZzZHBvcnQuYyB8IDIgKy0KIDIgZmlsZXMgY2hhbmdlZCwgMSBpbnNlcnRpb24oKyks IDMgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvc3lzL2ZzL25mcy9uZnNkcG9ydC5oIGIv c3lzL2ZzL25mcy9uZnNkcG9ydC5oCmluZGV4IDUyOWFkYTIuLmEwOWE2ZGQgMTAwNjQ0Ci0t LSBhL3N5cy9mcy9uZnMvbmZzZHBvcnQuaAorKysgYi9zeXMvZnMvbmZzL25mc2Rwb3J0LmgK QEAgLTk0LDggKzk0LDYgQEAgc3RydWN0IG5mc2V4c3R1ZmYgewogI2RlZmluZQlORlNGUENS RUQoZikJKChmKS0+Zl9jcmVkKQogI2RlZmluZQlORlNGUEZMQUcoZikJKChmKS0+Zl9mbGFn KQogCi1pbnQgZnBfZ2V0ZnZwKE5GU1BST0NfVCAqLCBpbnQsIHN0cnVjdCBmaWxlICoqLCBz dHJ1Y3Qgdm5vZGUgKiopOwotCiAjZGVmaW5lCU5GU05BTUVJQ05EU0VUKG4sIGMsIG8sIGYp CWRvIHsJCQkJXAogCShuKS0+Y25fY3JlZCA9IChjKTsJCQkJCQlcCiAJKG4pLT5jbl9uYW1l aW9wID0gKG8pOwkJCQkJCVwKZGlmZiAtLWdpdCBhL3N5cy9mcy9uZnNzZXJ2ZXIvbmZzX25m c2Rwb3J0LmMgYi9zeXMvZnMvbmZzc2VydmVyL25mc19uZnNkcG9ydC5jCmluZGV4IGNkNzgx NGMuLjg4MGY5NjUgMTAwNjQ0Ci0tLSBhL3N5cy9mcy9uZnNzZXJ2ZXIvbmZzX25mc2Rwb3J0 LmMKKysrIGIvc3lzL2ZzL25mc3NlcnZlci9uZnNfbmZzZHBvcnQuYwpAQCAtMjc2Nyw3ICsy NzY3LDcgQEAgb3V0OgogLyoKICAqIGdsdWUgZm9yIGZwLgogICovCi1pbnQKK3N0YXRpYyBp bnQKIGZwX2dldGZ2cChzdHJ1Y3QgdGhyZWFkICpwLCBpbnQgZmQsIHN0cnVjdCBmaWxlICoq ZnBwLCBzdHJ1Y3Qgdm5vZGUgKip2cHApCiB7CiAJc3RydWN0IGZpbGVkZXNjICpmZHA7Ci0t IAoxLjguMS4zCgo= --------------060105070608040709090402 Content-Type: text/plain; charset=UTF-8; name="0011-Use-simple-assignment-instead-of-bcopy-to-copy-struc.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename*0="0011-Use-simple-assignment-instead-of-bcopy-to-copy-struc.pa"; filename*1="tch" RnJvbSA0NjQ1Y2M2ZGI1NGYyOWMxZjVlYzMyYzQ3Nzk0ZmQxMzVmOTljZjYwIE1vbiBTZXAg MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBDaHJpc3RvcGggTWFsbG9uIDxjaHJpc3RvcGgubWFs bG9uQGdteC5kZT4KRGF0ZTogU3VuLCAyNCBGZWIgMjAxMyAxMzozNzoyMiArMDEwMApTdWJq ZWN0OiBbUEFUQ0ggMTEvMjRdIFVzZSBzaW1wbGUgYXNzaWdubWVudCBpbnN0ZWFkIG9mIGJj b3B5KCkgdG8gY29weQogc3RydWN0cy4KCi0tLQogc3lzL2tlcm4va2Vybl9kZXNjcmlwLmMg fCAxNSArKysrKystLS0tLS0tLS0KIDEgZmlsZSBjaGFuZ2VkLCA2IGluc2VydGlvbnMoKyks IDkgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvc3lzL2tlcm4va2Vybl9kZXNjcmlwLmMg Yi9zeXMva2Vybi9rZXJuX2Rlc2NyaXAuYwppbmRleCA0NzNhYjQwLi45NGJiNzRhIDEwMDY0 NAotLS0gYS9zeXMva2Vybi9rZXJuX2Rlc2NyaXAuYworKysgYi9zeXMva2Vybi9rZXJuX2Rl c2NyaXAuYwpAQCAtODM5LDggKzgzOSw3IEBAIGRvX2R1cChzdHJ1Y3QgdGhyZWFkICp0ZCwg aW50IGZsYWdzLCBpbnQgb2xkLCBpbnQgbmV3LAogCS8qCiAJICogRHVwbGljYXRlIHRoZSBz b3VyY2UgZGVzY3JpcHRvci4KIAkgKi8KLQliY29weSgmZmRwLT5mZF9vZmlsZXNbb2xkXSwg JmZkcC0+ZmRfb2ZpbGVzW25ld10sCi0JICAgIHNpemVvZihmZHAtPmZkX29maWxlc1tuZXdd KSk7CisJZmRwLT5mZF9vZmlsZXNbbmV3XSA9IGZkcC0+ZmRfb2ZpbGVzW29sZF07CiAJZmls ZWNhcHNfY29weSgmZmRwLT5mZF9vZmlsZXNbb2xkXS5mZGVfY2FwcywKIAkgICAgJmZkcC0+ ZmRfb2ZpbGVzW25ld10uZmRlX2NhcHMpOwogCWlmICgoZmxhZ3MgJiBEVVBfQ0xPRVhFQykg IT0gMCkgewpAQCAtMTM3NCw3ICsxMzczLDcgQEAgZmlsZWNhcHNfY29weShjb25zdCBzdHJ1 Y3QgZmlsZWNhcHMgKnNyYywgc3RydWN0IGZpbGVjYXBzICpkc3QpCiB7CiAJc2l6ZV90IHNp emU7CiAKLQliY29weShzcmMsIGRzdCwgc2l6ZW9mKCpkc3QpKTsKKwkqZHN0ID0gKnNyYzsK IAlpZiAoc3JjLT5mY19pb2N0bHMgIT0gTlVMTCkgewogCQlLQVNTRVJUKHNyYy0+ZmNfbmlv Y3RscyA+IDAsCiAJCSAgICAoImZjX2lvY3RscyAhPSBOVUxMLCBidXQgZmNfbmlvY3Rscz0l aGQiLCBzcmMtPmZjX25pb2N0bHMpKTsKQEAgLTEzOTIsNyArMTM5MSw3IEBAIHN0YXRpYyB2 b2lkCiBmaWxlY2Fwc19tb3ZlKHN0cnVjdCBmaWxlY2FwcyAqc3JjLCBzdHJ1Y3QgZmlsZWNh cHMgKmRzdCkKIHsKIAotCWJjb3B5KHNyYywgZHN0LCBzaXplb2YoKmRzdCkpOworCSpkc3Qg PSAqc3JjOwogCWJ6ZXJvKHNyYywgc2l6ZW9mKCpzcmMpKTsKIH0KIApAQCAtMTgzNSw3ICsx ODM0LDcgQEAgZmRjb3B5KHN0cnVjdCBmaWxlZGVzYyAqZmRwKQogCQkgICAgKG9mZGUtPmZk ZV9maWxlLT5mX29wcy0+Zm9fZmxhZ3MgJiBERkxBR19QQVNTQUJMRSkgJiYKIAkJICAgIG9m ZGUtPmZkZV9maWxlLT5mX29wcyAhPSAmYmFkZmlsZW9wcykgewogCQkJbmZkZSA9ICZuZXdm ZHAtPmZkX29maWxlc1tpXTsKLQkJCWJjb3B5KG9mZGUsIG5mZGUsIHNpemVvZigqbmZkZSkp OworCQkJKm5mZGUgPSAqb2ZkZTsKIAkJCWZpbGVjYXBzX2NvcHkoJm9mZGUtPmZkZV9jYXBz LCAmbmZkZS0+ZmRlX2NhcHMpOwogCQkJZmhvbGQobmZkZS0+ZmRlX2ZpbGUpOwogCQkJbmV3 ZmRwLT5mZF9sYXN0ZmlsZSA9IGk7CkBAIC0yNjgxLDggKzI2ODAsNyBAQCBkdXBmZG9wZW4o c3RydWN0IHRocmVhZCAqdGQsIHN0cnVjdCBmaWxlZGVzYyAqZmRwLCBpbnQgZGZkLCBpbnQg bW9kZSwKIAkJCXJldHVybiAoRUFDQ0VTKTsKIAkJfQogCQlmaG9sZChmcCk7Ci0JCWJjb3B5 KCZmZHAtPmZkX29maWxlc1tkZmRdLCAmZmRwLT5mZF9vZmlsZXNbaW5keF0sCi0JCSAgICBz aXplb2YoZmRwLT5mZF9vZmlsZXNbaW5keF0pKTsKKwkJZmRwLT5mZF9vZmlsZXNbaW5keF0g PSBmZHAtPmZkX29maWxlc1tkZmRdOwogCQlmaWxlY2Fwc19jb3B5KCZmZHAtPmZkX29maWxl c1tkZmRdLmZkZV9jYXBzLAogCQkgICAgJmZkcC0+ZmRfb2ZpbGVzW2luZHhdLmZkZV9jYXBz KTsKIAkJYnJlYWs7CkBAIC0yNjkwLDggKzI2ODgsNyBAQCBkdXBmZG9wZW4oc3RydWN0IHRo cmVhZCAqdGQsIHN0cnVjdCBmaWxlZGVzYyAqZmRwLCBpbnQgZGZkLCBpbnQgbW9kZSwKIAkJ LyoKIAkJICogU3RlYWwgYXdheSB0aGUgZmlsZSBwb2ludGVyIGZyb20gZGZkIGFuZCBzdHVm ZiBpdCBpbnRvIGluZHguCiAJCSAqLwotCQliY29weSgmZmRwLT5mZF9vZmlsZXNbZGZkXSwg JmZkcC0+ZmRfb2ZpbGVzW2luZHhdLAotCQkgICAgc2l6ZW9mKGZkcC0+ZmRfb2ZpbGVzW2lu ZHhdKSk7CisJCWZkcC0+ZmRfb2ZpbGVzW2luZHhdID0gZmRwLT5mZF9vZmlsZXNbZGZkXTsK IAkJYnplcm8oJmZkcC0+ZmRfb2ZpbGVzW2RmZF0sIHNpemVvZihmZHAtPmZkX29maWxlc1tk ZmRdKSk7CiAJCWZkdW51c2VkKGZkcCwgZGZkKTsKIAkJYnJlYWs7Ci0tIAoxLjguMS4zCgo= --------------060105070608040709090402 Content-Type: text/plain; charset=UTF-8; name="0012-Remove-redundant-null-pointer-tests-before-free.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename*0="0012-Remove-redundant-null-pointer-tests-before-free.patch" RnJvbSBmYzg4NzhkMGE0M2VhM2Y5ZDc3YjFmZDUxZjkwZjRiNGJlMTg4ZmIyIE1vbiBTZXAg MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBDaHJpc3RvcGggTWFsbG9uIDxjaHJpc3RvcGgubWFs bG9uQGdteC5kZT4KRGF0ZTogU3VuLCAyNCBGZWIgMjAxMyAxMzo0MDozMiArMDEwMApTdWJq ZWN0OiBbUEFUQ0ggMTIvMjRdIFJlbW92ZSByZWR1bmRhbnQgbnVsbCBwb2ludGVyIHRlc3Rz IGJlZm9yZSBmcmVlKCkuCgotLS0KIHN5cy9rZXJuL2tlcm5fZGVzY3JpcC5jICAgfCAgMyAr LS0KIHN5cy9rZXJuL3N5c19jYXBhYmlsaXR5LmMgfCAxNSArKysrKy0tLS0tLS0tLS0KIDIg ZmlsZXMgY2hhbmdlZCwgNiBpbnNlcnRpb25zKCspLCAxMiBkZWxldGlvbnMoLSkKCmRpZmYg LS1naXQgYS9zeXMva2Vybi9rZXJuX2Rlc2NyaXAuYyBiL3N5cy9rZXJuL2tlcm5fZGVzY3Jp cC5jCmluZGV4IDk0YmI3NGEuLjUzYjI0YjEgMTAwNjQ0Ci0tLSBhL3N5cy9rZXJuL2tlcm5f ZGVzY3JpcC5jCisrKyBiL3N5cy9rZXJuL2tlcm5fZGVzY3JpcC5jCkBAIC0xNDE1LDggKzE0 MTUsNyBAQCB2b2lkCiBmaWxlY2Fwc19mcmVlKHN0cnVjdCBmaWxlY2FwcyAqZmNhcHMpCiB7 CiAKLQlpZiAoZmNhcHMtPmZjX2lvY3RscyAhPSBOVUxMKQotCQlmcmVlKGZjYXBzLT5mY19p b2N0bHMsIE1fVEVNUCk7CisJZnJlZShmY2Fwcy0+ZmNfaW9jdGxzLCBNX1RFTVApOwogCWJ6 ZXJvKGZjYXBzLCBzaXplb2YoKmZjYXBzKSk7CiB9CiAKZGlmZiAtLWdpdCBhL3N5cy9rZXJu L3N5c19jYXBhYmlsaXR5LmMgYi9zeXMva2Vybi9zeXNfY2FwYWJpbGl0eS5jCmluZGV4IDBm NGVmMTIuLmVjYjNhNmIgMTAwNjQ0Ci0tLSBhL3N5cy9rZXJuL3N5c19jYXBhYmlsaXR5LmMK KysrIGIvc3lzL2tlcm4vc3lzX2NhcGFiaWxpdHkuYwpAQCAtMjI4LDEwICsyMjgsOCBAQCBz eXNfY2FwX3JpZ2h0c19saW1pdChzdHJ1Y3QgdGhyZWFkICp0ZCwgc3RydWN0IGNhcF9yaWdo dHNfbGltaXRfYXJncyAqdWFwKQogCWlmIChlcnJvciA9PSAwKSB7CiAJCWZkcC0+ZmRfb2Zp bGVzW2ZkXS5mZGVfcmlnaHRzID0gcmlnaHRzOwogCQlpZiAoKHJpZ2h0cyAmIENBUF9JT0NU TCkgPT0gMCkgewotCQkJaWYgKGZkcC0+ZmRfb2ZpbGVzW2ZkXS5mZGVfaW9jdGxzICE9IE5V TEwpIHsKLQkJCQlmcmVlKGZkcC0+ZmRfb2ZpbGVzW2ZkXS5mZGVfaW9jdGxzLCBNX1RFTVAp OwotCQkJCWZkcC0+ZmRfb2ZpbGVzW2ZkXS5mZGVfaW9jdGxzID0gTlVMTDsKLQkJCX0KKwkJ CWZyZWUoZmRwLT5mZF9vZmlsZXNbZmRdLmZkZV9pb2N0bHMsIE1fVEVNUCk7CisJCQlmZHAt PmZkX29maWxlc1tmZF0uZmRlX2lvY3RscyA9IE5VTEw7CiAJCQlmZHAtPmZkX29maWxlc1tm ZF0uZmRlX25pb2N0bHMgPSAwOwogCQl9CiAJCWlmICgocmlnaHRzICYgQ0FQX0ZDTlRMKSA9 PSAwICYmCkBAIC0zNzYsOCArMzc0LDcgQEAgc3lzX2NhcF9pb2N0bHNfbGltaXQoc3RydWN0 IHRocmVhZCAqdGQsIHN0cnVjdCBjYXBfaW9jdGxzX2xpbWl0X2FyZ3MgKnVhcCkKIAogCUZJ TEVERVNDX1hVTkxPQ0soZmRwKTsKIAotCWlmIChvY21kcyAhPSBOVUxMKQotCQlmcmVlKG9j bWRzLCBNX1RFTVApOworCWZyZWUob2NtZHMsIE1fVEVNUCk7CiAKIAlyZXR1cm4gKDApOwog fQpAQCAtNTU2LDEwICs1NTMsOCBAQCBzeXNfY2FwX25ldyhzdHJ1Y3QgdGhyZWFkICp0ZCwg c3RydWN0IGNhcF9uZXdfYXJncyAqdWFwKQogCSAqLwogCWZkcC0+ZmRfb2ZpbGVzW25ld2Zk XS5mZGVfcmlnaHRzID0gcmlnaHRzOwogCWlmICgocmlnaHRzICYgQ0FQX0lPQ1RMKSA9PSAw KSB7Ci0JCWlmIChmZHAtPmZkX29maWxlc1tuZXdmZF0uZmRlX2lvY3RscyAhPSBOVUxMKSB7 Ci0JCQlmcmVlKGZkcC0+ZmRfb2ZpbGVzW25ld2ZkXS5mZGVfaW9jdGxzLCBNX1RFTVApOwot CQkJZmRwLT5mZF9vZmlsZXNbbmV3ZmRdLmZkZV9pb2N0bHMgPSBOVUxMOwotCQl9CisJCWZy ZWUoZmRwLT5mZF9vZmlsZXNbbmV3ZmRdLmZkZV9pb2N0bHMsIE1fVEVNUCk7CisJCWZkcC0+ ZmRfb2ZpbGVzW25ld2ZkXS5mZGVfaW9jdGxzID0gTlVMTDsKIAkJZmRwLT5mZF9vZmlsZXNb bmV3ZmRdLmZkZV9uaW9jdGxzID0gMDsKIAl9CiAJaWYgKChyaWdodHMgJiBDQVBfRkNOVEwp ID09IDAgJiYgZmRwLT5mZF9vZmlsZXNbbmV3ZmRdLmZkZV9mY250bHMgIT0gMCkKLS0gCjEu OC4xLjMKCg== --------------060105070608040709090402 Content-Type: text/plain; charset=UTF-8; name="0013-Remove-redundant-test.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="0013-Remove-redundant-test.patch" RnJvbSA0MWZjMWYzOWExODMzMWY1N2U2YTAzYjU0ZjRiNzhjYmJkMTIzY2Q1IE1vbiBTZXAg MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBDaHJpc3RvcGggTWFsbG9uIDxjaHJpc3RvcGgubWFs bG9uQGdteC5kZT4KRGF0ZTogU3VuLCAyNCBGZWIgMjAxMyAxMzo0MTozOCArMDEwMApTdWJq ZWN0OiBbUEFUQ0ggMTMvMjRdIFJlbW92ZSByZWR1bmRhbnQgdGVzdC4KCmlmIG5lZWRyaWdo dHMgaXMgMCwgdGhlIGlubmVyIHRlc3RzIHdpbGwgc3VjY2VlZC4KLS0tCiBzeXMva2Vybi9r ZXJuX2Rlc2NyaXAuYyB8IDEyICsrKysrLS0tLS0tLQogMSBmaWxlIGNoYW5nZWQsIDUgaW5z ZXJ0aW9ucygrKSwgNyBkZWxldGlvbnMoLSkKCmRpZmYgLS1naXQgYS9zeXMva2Vybi9rZXJu X2Rlc2NyaXAuYyBiL3N5cy9rZXJuL2tlcm5fZGVzY3JpcC5jCmluZGV4IDUzYjI0YjEuLmQx NDY1YTAgMTAwNjQ0Ci0tLSBhL3N5cy9rZXJuL2tlcm5fZGVzY3JpcC5jCisrKyBiL3N5cy9r ZXJuL2tlcm5fZGVzY3JpcC5jCkBAIC0yMjcwLDE1ICsyMjcwLDEzIEBAIGZnZXRfdW5sb2Nr ZWQoc3RydWN0IGZpbGVkZXNjICpmZHAsIGludCBmZCwgY2FwX3JpZ2h0c190IG5lZWRyaWdo dHMsCiAJCQlyZXR1cm4gKEVCQURGKTsKICNpZmRlZiBDQVBBQklMSVRJRVMKIAkJaGF2ZXJp Z2h0cyA9IGNhcF9yaWdodHMoZmRwLCBmZCk7Ci0JCWlmIChuZWVkcmlnaHRzICE9IDApIHsK LQkJCWVycm9yID0gY2FwX2NoZWNrKGhhdmVyaWdodHMsIG5lZWRyaWdodHMpOworCQllcnJv ciA9IGNhcF9jaGVjayhoYXZlcmlnaHRzLCBuZWVkcmlnaHRzKTsKKwkJaWYgKGVycm9yICE9 IDApCisJCQlyZXR1cm4gKGVycm9yKTsKKwkJaWYgKChuZWVkcmlnaHRzICYgQ0FQX0ZDTlRM KSAhPSAwKSB7CisJCQllcnJvciA9IGNhcF9mY250bF9jaGVjayhmZHAsIGZkLCBuZWVkZmNu dGwpOwogCQkJaWYgKGVycm9yICE9IDApCiAJCQkJcmV0dXJuIChlcnJvcik7Ci0JCQlpZiAo KG5lZWRyaWdodHMgJiBDQVBfRkNOVEwpICE9IDApIHsKLQkJCQllcnJvciA9IGNhcF9mY250 bF9jaGVjayhmZHAsIGZkLCBuZWVkZmNudGwpOwotCQkJCWlmIChlcnJvciAhPSAwKQotCQkJ CQlyZXR1cm4gKGVycm9yKTsKLQkJCX0KIAkJfQogI2VuZGlmCiAJCWNvdW50ID0gZnAtPmZf Y291bnQ7Ci0tIAoxLjguMS4zCgo= --------------060105070608040709090402 Content-Type: text/plain; charset=UTF-8; name="0014-Avoide-double-test.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="0014-Avoide-double-test.patch" RnJvbSBkNGM4ZTZiYmViNjc4ODY3YjJiZDFjMGVjMDlmYWY2MDY0MjQ2NWQwIE1vbiBTZXAg MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBDaHJpc3RvcGggTWFsbG9uIDxjaHJpc3RvcGgubWFs bG9uQGdteC5kZT4KRGF0ZTogU3VuLCAyNCBGZWIgMjAxMyAxMzo0MzoyOCArMDEwMApTdWJq ZWN0OiBbUEFUQ0ggMTQvMjRdIEF2b2lkZSBkb3VibGUgdGVzdC4KCi0tLQogc3lzL2tlcm4v c3lzX2NhcGFiaWxpdHkuYyB8IDYgKysrLS0tCiAxIGZpbGUgY2hhbmdlZCwgMyBpbnNlcnRp b25zKCspLCAzIGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL3N5cy9rZXJuL3N5c19jYXBh YmlsaXR5LmMgYi9zeXMva2Vybi9zeXNfY2FwYWJpbGl0eS5jCmluZGV4IGVjYjNhNmIuLmRi YmRhMDEgMTAwNjQ0Ci0tLSBhL3N5cy9rZXJuL3N5c19jYXBhYmlsaXR5LmMKKysrIGIvc3lz L2tlcm4vc3lzX2NhcGFiaWxpdHkuYwpAQCAtMzE0LDEyICszMTQsMTIgQEAgY2FwX2lvY3Rs X2xpbWl0X2NoZWNrKHN0cnVjdCBmaWxlZGVzYyAqZmRwLCBpbnQgZmQsIGNvbnN0IHVfbG9u ZyAqY21kcywKIAogCW9jbWRzID0gZmRwLT5mZF9vZmlsZXNbZmRdLmZkZV9pb2N0bHM7CiAJ Zm9yIChpID0gMDsgaSA8IG5jbWRzOyBpKyspIHsKLQkJZm9yIChqID0gMDsgaiA8IG9uY21k czsgaisrKSB7CisJCWZvciAoaiA9IDA7OyBqKyspIHsKKwkJCWlmIChqID09IG9uY21kcykK KwkJCQlyZXR1cm4gKEVOT1RDQVBBQkxFKTsKIAkJCWlmIChjbWRzW2ldID09IG9jbWRzW2pd KQogCQkJCWJyZWFrOwogCQl9Ci0JCWlmIChqID09IG9uY21kcykKLQkJCXJldHVybiAoRU5P VENBUEFCTEUpOwogCX0KIAogCXJldHVybiAoMCk7Ci0tIAoxLjguMS4zCgo= --------------060105070608040709090402 Content-Type: text/plain; charset=UTF-8; name="0015-Simplify-if-x-0-x-0-to-just-x-0.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="0015-Simplify-if-x-0-x-0-to-just-x-0.patch" RnJvbSBiYTEwMjc0YWI0OGJmOWIyYTJlNmI4ZDUwYzU5ZWIyNDA3NGU2ZWMwIE1vbiBTZXAg MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBDaHJpc3RvcGggTWFsbG9uIDxjaHJpc3RvcGgubWFs bG9uQGdteC5kZT4KRGF0ZTogU3VuLCAyNCBGZWIgMjAxMyAxMzo0NTowOSArMDEwMApTdWJq ZWN0OiBbUEFUQ0ggMTUvMjRdIFNpbXBsaWZ5IGlmICh4ICE9IDApIHggPSAwOyB0byBqdXN0 IHggPSAwOy4KCi0tLQogc3lzL2tlcm4vc3lzX2NhcGFiaWxpdHkuYyB8IDYgKystLS0tCiAx IGZpbGUgY2hhbmdlZCwgMiBpbnNlcnRpb25zKCspLCA0IGRlbGV0aW9ucygtKQoKZGlmZiAt LWdpdCBhL3N5cy9rZXJuL3N5c19jYXBhYmlsaXR5LmMgYi9zeXMva2Vybi9zeXNfY2FwYWJp bGl0eS5jCmluZGV4IGRiYmRhMDEuLjE1MzM2NGIgMTAwNjQ0Ci0tLSBhL3N5cy9rZXJuL3N5 c19jYXBhYmlsaXR5LmMKKysrIGIvc3lzL2tlcm4vc3lzX2NhcGFiaWxpdHkuYwpAQCAtMjMy LDEwICsyMzIsOCBAQCBzeXNfY2FwX3JpZ2h0c19saW1pdChzdHJ1Y3QgdGhyZWFkICp0ZCwg c3RydWN0IGNhcF9yaWdodHNfbGltaXRfYXJncyAqdWFwKQogCQkJZmRwLT5mZF9vZmlsZXNb ZmRdLmZkZV9pb2N0bHMgPSBOVUxMOwogCQkJZmRwLT5mZF9vZmlsZXNbZmRdLmZkZV9uaW9j dGxzID0gMDsKIAkJfQotCQlpZiAoKHJpZ2h0cyAmIENBUF9GQ05UTCkgPT0gMCAmJgotCQkg ICAgZmRwLT5mZF9vZmlsZXNbZmRdLmZkZV9mY250bHMgIT0gMCkgeworCQlpZiAoKHJpZ2h0 cyAmIENBUF9GQ05UTCkgPT0gMCkKIAkJCWZkcC0+ZmRfb2ZpbGVzW2ZkXS5mZGVfZmNudGxz ID0gMDsKLQkJfQogCX0KIAlGSUxFREVTQ19YVU5MT0NLKGZkcCk7CiAJcmV0dXJuIChlcnJv cik7CkBAIC01NTcsNyArNTU1LDcgQEAgc3lzX2NhcF9uZXcoc3RydWN0IHRocmVhZCAqdGQs IHN0cnVjdCBjYXBfbmV3X2FyZ3MgKnVhcCkKIAkJZmRwLT5mZF9vZmlsZXNbbmV3ZmRdLmZk ZV9pb2N0bHMgPSBOVUxMOwogCQlmZHAtPmZkX29maWxlc1tuZXdmZF0uZmRlX25pb2N0bHMg PSAwOwogCX0KLQlpZiAoKHJpZ2h0cyAmIENBUF9GQ05UTCkgPT0gMCAmJiBmZHAtPmZkX29m aWxlc1tuZXdmZF0uZmRlX2ZjbnRscyAhPSAwKQorCWlmICgocmlnaHRzICYgQ0FQX0ZDTlRM KSA9PSAwKQogCQlmZHAtPmZkX29maWxlc1tuZXdmZF0uZmRlX2ZjbnRscyA9IDA7CiAJRklM RURFU0NfWFVOTE9DSyhmZHApOwogCi0tIAoxLjguMS4zCgo= --------------060105070608040709090402 Content-Type: text/plain; charset=UTF-8; name="0016-Reduce-indentation.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="0016-Reduce-indentation.patch" RnJvbSAzOGVjNTUzMzg3MTRlNjhiODQ1ZWU0NTI3MmZhYzdlNzMzMzcyN2VmIE1vbiBTZXAg MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBDaHJpc3RvcGggTWFsbG9uIDxjaHJpc3RvcGgubWFs bG9uQGdteC5kZT4KRGF0ZTogU3VuLCAyNCBGZWIgMjAxMyAxMzo0NzoyMyArMDEwMApTdWJq ZWN0OiBbUEFUQ0ggMTYvMjRdIFJlZHVjZSBpbmRlbnRhdGlvbi4KCi0tLQogc3lzL2tlcm4v a2Vybl9kZXNjcmlwLmMgfCAxNCArKysrKystLS0tLS0tLQogMSBmaWxlIGNoYW5nZWQsIDYg aW5zZXJ0aW9ucygrKSwgOCBkZWxldGlvbnMoLSkKCmRpZmYgLS1naXQgYS9zeXMva2Vybi9r ZXJuX2Rlc2NyaXAuYyBiL3N5cy9rZXJuL2tlcm5fZGVzY3JpcC5jCmluZGV4IGQxNDY1YTAu LjYxMmQ1MWEgMTAwNjQ0Ci0tLSBhL3N5cy9rZXJuL2tlcm5fZGVzY3JpcC5jCisrKyBiL3N5 cy9rZXJuL2tlcm5fZGVzY3JpcC5jCkBAIC0yNDYzLDE1ICsyNDYzLDEzIEBAIGZnZXR2cF9y aWdodHMoc3RydWN0IHRocmVhZCAqdGQsIGludCBmZCwgY2FwX3JpZ2h0c190IG5lZWQsCiAJ aWYgKGVycm9yICE9IDApCiAJCXJldHVybiAoZXJyb3IpOwogCi0JaWYgKGZwLT5mX3Zub2Rl ID09IE5VTEwpIHsKLQkJZXJyb3IgPSBFSU5WQUw7Ci0JfSBlbHNlIHsKLQkJKnZwcCA9IGZw LT5mX3Zub2RlOwotCQl2cmVmKCp2cHApOwotCQlmaWxlY2Fwc19jb3B5KCZmZHAtPmZkX29m aWxlc1tmZF0uZmRlX2NhcHMsIGhhdmVjYXBzKTsKLQl9CisJaWYgKGZwLT5mX3Zub2RlID09 IE5VTEwpCisJCXJldHVybiBFSU5WQUw7CiAKLQlyZXR1cm4gKGVycm9yKTsKKwkqdnBwID0g ZnAtPmZfdm5vZGU7CisJdnJlZigqdnBwKTsKKwlmaWxlY2Fwc19jb3B5KCZmZHAtPmZkX29m aWxlc1tmZF0uZmRlX2NhcHMsIGhhdmVjYXBzKTsKKwlyZXR1cm4gKDApOwogfQogCiBpbnQK LS0gCjEuOC4xLjMKCg== --------------060105070608040709090402 Content-Type: text/plain; charset=UTF-8; name="0017-Avoid-code-duplication-on-error-paths.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="0017-Avoid-code-duplication-on-error-paths.patch" RnJvbSA2NGU2NjI3N2MyNjViM2ExMjIxZDllMjY5YzhmMzMzNDVlNDMzMzJjIE1vbiBTZXAg MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBDaHJpc3RvcGggTWFsbG9uIDxjaHJpc3RvcGgubWFs bG9uQGdteC5kZT4KRGF0ZTogU3VuLCAyNCBGZWIgMjAxMyAxMzo0OTozNyArMDEwMApTdWJq ZWN0OiBbUEFUQ0ggMTcvMjRdIEF2b2lkIGNvZGUgZHVwbGljYXRpb24gb24gZXJyb3IgcGF0 aHMuCgotLS0KIHN5cy9rZXJuL3N5c19jYXBhYmlsaXR5LmMgfCA0MiArKysrKysrKysrKysr KysrKystLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KIDEgZmlsZSBjaGFuZ2VkLCAxOCBpbnNl cnRpb25zKCspLCAyNCBkZWxldGlvbnMoLSkKCmRpZmYgLS1naXQgYS9zeXMva2Vybi9zeXNf Y2FwYWJpbGl0eS5jIGIvc3lzL2tlcm4vc3lzX2NhcGFiaWxpdHkuYwppbmRleCAxNTMzNjRi Li5lODdhNGU1IDEwMDY0NAotLS0gYS9zeXMva2Vybi9zeXNfY2FwYWJpbGl0eS5jCisrKyBi L3N5cy9rZXJuL3N5c19jYXBhYmlsaXR5LmMKQEAgLTM0NCwzNyArMzQ0LDMyIEBAIHN5c19j YXBfaW9jdGxzX2xpbWl0KHN0cnVjdCB0aHJlYWQgKnRkLCBzdHJ1Y3QgY2FwX2lvY3Rsc19s aW1pdF9hcmdzICp1YXApCiAJfSBlbHNlIHsKIAkJY21kcyA9IG1hbGxvYyhzaXplb2YoY21k c1swXSkgKiBuY21kcywgTV9URU1QLCBNX1dBSVRPSyk7CiAJCWVycm9yID0gY29weWluKHVh cC0+Y21kcywgY21kcywgc2l6ZW9mKGNtZHNbMF0pICogbmNtZHMpOwotCQlpZiAoZXJyb3Ig IT0gMCkgewotCQkJZnJlZShjbWRzLCBNX1RFTVApOwotCQkJcmV0dXJuIChlcnJvcik7Ci0J CX0KKwkJaWYgKGVycm9yICE9IDApCisJCQlnb3RvIG91dDsKIAl9CiAKIAlmZHAgPSB0ZC0+ dGRfcHJvYy0+cF9mZDsKIAlGSUxFREVTQ19YTE9DSyhmZHApOwogCiAJaWYgKGZnZXRfbG9j a2VkKGZkcCwgZmQpID09IE5VTEwpIHsKLQkJRklMRURFU0NfWFVOTE9DSyhmZHApOwotCQlm cmVlKGNtZHMsIE1fVEVNUCk7Ci0JCXJldHVybiAoRUJBREYpOworCQllcnJvciA9IEVCQURG OworCQlnb3RvIG91dF9sb2NrZWQ7CiAJfQogCiAJZXJyb3IgPSBjYXBfaW9jdGxfbGltaXRf Y2hlY2soZmRwLCBmZCwgY21kcywgbmNtZHMpOwotCWlmIChlcnJvciAhPSAwKSB7Ci0JCUZJ TEVERVNDX1hVTkxPQ0soZmRwKTsKLQkJZnJlZShjbWRzLCBNX1RFTVApOwotCQlyZXR1cm4g KGVycm9yKTsKLQl9CisJaWYgKGVycm9yICE9IDApCisJCWdvdG8gb3V0X2xvY2tlZDsKIAog CW9jbWRzID0gZmRwLT5mZF9vZmlsZXNbZmRdLmZkZV9pb2N0bHM7CiAJZmRwLT5mZF9vZmls ZXNbZmRdLmZkZV9pb2N0bHMgPSBjbWRzOwogCWZkcC0+ZmRfb2ZpbGVzW2ZkXS5mZGVfbmlv Y3RscyA9IG5jbWRzOworCWNtZHMgPSBvY21kczsKIAorb3V0X2xvY2tlZDoKIAlGSUxFREVT Q19YVU5MT0NLKGZkcCk7Ci0KLQlmcmVlKG9jbWRzLCBNX1RFTVApOwotCi0JcmV0dXJuICgw KTsKK291dDoKKwlmcmVlKGNtZHMsIE1fVEVNUCk7CisJcmV0dXJuIChlcnJvcik7CiB9CiAK IGludApAQCAtMzk2LDggKzM5MSw4IEBAIHN5c19jYXBfaW9jdGxzX2dldChzdHJ1Y3QgdGhy ZWFkICp0ZCwgc3RydWN0IGNhcF9pb2N0bHNfZ2V0X2FyZ3MgKnVhcCkKIAlGSUxFREVTQ19T TE9DSyhmZHApOwogCiAJaWYgKGZnZXRfbG9ja2VkKGZkcCwgZmQpID09IE5VTEwpIHsKLQkJ RklMRURFU0NfU1VOTE9DSyhmZHApOwotCQlyZXR1cm4gKEVCQURGKTsKKwkJZXJyb3IgPSBF QkFERjsKKwkJZ290byBvdXQ7CiAJfQogCiAJLyoKQEAgLTQxMCwxOSArNDA1LDE4IEBAIHN5 c19jYXBfaW9jdGxzX2dldChzdHJ1Y3QgdGhyZWFkICp0ZCwgc3RydWN0IGNhcF9pb2N0bHNf Z2V0X2FyZ3MgKnVhcCkKIAlpZiAoY21kcyAhPSBOVUxMICYmIGZkZXAtPmZkZV9pb2N0bHMg IT0gTlVMTCkgewogCQllcnJvciA9IGNvcHlvdXQoZmRlcC0+ZmRlX2lvY3RscywgY21kcywK IAkJICAgIHNpemVvZihjbWRzWzBdKSAqIE1JTihmZGVwLT5mZGVfbmlvY3RscywgbWF4Y21k cykpOwotCQlpZiAoZXJyb3IgIT0gMCkgewotCQkJRklMRURFU0NfU1VOTE9DSyhmZHApOwot CQkJcmV0dXJuIChlcnJvcik7Ci0JCX0KKwkJaWYgKGVycm9yICE9IDApCisJCQlnb3RvIG91 dDsKIAl9CiAJaWYgKGZkZXAtPmZkZV9uaW9jdGxzID09IC0xKQogCQl0ZC0+dGRfcmV0dmFs WzBdID0gSU5UX01BWDsKIAllbHNlCiAJCXRkLT50ZF9yZXR2YWxbMF0gPSBmZGVwLT5mZGVf bmlvY3RsczsKKwllcnJvciA9IDA7CiAKK291dDoKIAlGSUxFREVTQ19TVU5MT0NLKGZkcCk7 Ci0KLQlyZXR1cm4gKDApOworCXJldHVybiAoZXJyb3IpOwogfQogCiAvKgotLSAKMS44LjEu MwoK --------------060105070608040709090402 Content-Type: text/plain; charset=UTF-8; name="0018-Hopefully-slightly-improve-manpages-and-comments.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename*0="0018-Hopefully-slightly-improve-manpages-and-comments.patch" RnJvbSAwZTY5MmUwNWFjY2Q1NmE0ZGIxZjkzOGFkN2FhNGM1MDk3OWE2MTQ4IE1vbiBTZXAg MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBDaHJpc3RvcGggTWFsbG9uIDxjaHJpc3RvcGgubWFs bG9uQGdteC5kZT4KRGF0ZTogU3VuLCAyNCBGZWIgMjAxMyAxNDowMDowMSArMDEwMApTdWJq ZWN0OiBbUEFUQ0ggMTgvMjRdIChIb3BlZnVsbHkpIHNsaWdodGx5IGltcHJvdmUgbWFucGFn ZXMgYW5kIGNvbW1lbnRzLgoKLS0tCiBsaWIvbGliYy9nZW4vY2FwX3NhbmRib3hlZC4zICAg IHwgIDYgKysrLS0tCiBsaWIvbGliYy9zeXMvY2FwX2ZjbnRsc19saW1pdC4yIHwgMTQgKysr KysrKy0tLS0tLS0KIGxpYi9saWJjL3N5cy9jYXBfaW9jdGxzX2xpbWl0LjIgfCAyNCArKysr KysrKysrKystLS0tLS0tLS0tLS0KIGxpYi9saWJjL3N5cy9jYXBfcmlnaHRzX2xpbWl0LjIg fCAxMCArKysrKy0tLS0tCiBzeXMvc3lzL2NhcGFiaWxpdHkuaCAgICAgICAgICAgIHwgIDQg KystLQogNSBmaWxlcyBjaGFuZ2VkLCAyOSBpbnNlcnRpb25zKCspLCAyOSBkZWxldGlvbnMo LSkKCmRpZmYgLS1naXQgYS9saWIvbGliYy9nZW4vY2FwX3NhbmRib3hlZC4zIGIvbGliL2xp YmMvZ2VuL2NhcF9zYW5kYm94ZWQuMwppbmRleCA0ODk2ZTAyLi4wNjdkNmQyIDEwMDY0NAot LS0gYS9saWIvbGliYy9nZW4vY2FwX3NhbmRib3hlZC4zCisrKyBiL2xpYi9saWJjL2dlbi9j YXBfc2FuZGJveGVkLjMKQEAgLTQ0LDEwICs0NCwxMCBAQAogLkZuIGNhcF9zYW5kYm94ZWQK IHJldHVybnMKIC5WYSB0cnVlCi1pcyB0aGUgcHJvY2VzcyBpcyBpbiBhIGNhcGFiaWxpdHkg bW9kZSBzYW5kYm94IG9yCitpZiB0aGUgcHJvY2VzcyBpcyBpbiBhIGNhcGFiaWxpdHkgbW9k ZSBzYW5kYm94IG9yCiAuVmEgZmFsc2UKIGlmIGl0IGlzIG5vdC4KLVRoaXMgZnVuY3Rpb24g aXMgbW9yZSBoYW5keSBhbHRlcm5hdGl2ZSB0byB0aGUKK1RoaXMgZnVuY3Rpb24gaXMgYSBt b3JlIGhhbmR5IGFsdGVybmF0aXZlIHRvIHRoZQogLlhyIGNhcF9nZXRtb2RlIDIKIHN5c3Rl bSBjYWxsIGFzIGl0IGFsd2F5cyBzdWNjZWVkcywgc28gdGhlcmUgaXMgbm8gbmVlZCBmb3Ig ZXJyb3IgY2hlY2tpbmcuCiBJZiB0aGUgc3VwcG9ydCBmb3IgY2FwYWJpbGl0eSBtb2RlIGlz IG5vdCBjb21waWxlZCBpbnRvIHRoZSBrZXJuZWwsCkBAIC01Nyw3ICs1Nyw3IEBAIHdpbGwg YWx3YXlzIHJldHVybgogLlNoIFJFVFVSTiBWQUxVRVMKIEZ1bmN0aW9uCiAuRm4gY2FwX3Nh bmRib3hlZAotaXMgYWx3YXlzIHN1Y2Nlc3NmdWwgYW5kIGNhbiByZXR1cm4gZWl0aGVyCitp cyBhbHdheXMgc3VjY2Vzc2Z1bCBhbmQgd2lsbCByZXR1cm4gZWl0aGVyCiAuVmEgdHJ1ZQog b3IKIC5WYSBmYWxzZSAuCmRpZmYgLS1naXQgYS9saWIvbGliYy9zeXMvY2FwX2ZjbnRsc19s aW1pdC4yIGIvbGliL2xpYmMvc3lzL2NhcF9mY250bHNfbGltaXQuMgppbmRleCAzOGFiOWNi Li44ZmE3NDYzIDEwMDY0NAotLS0gYS9saWIvbGliYy9zeXMvY2FwX2ZjbnRsc19saW1pdC4y CisrKyBiL2xpYi9saWJjL3N5cy9jYXBfZmNudGxzX2xpbWl0LjIKQEAgLTQ0LDE1ICs0NCwx NSBAQAogLkZ0IGludAogLkZuIGNhcF9mY250bHNfZ2V0ICJpbnQgZmQiICJ1aW50MzJfdCAq ZmNudGxyaWdodHNwIgogLlNoIERFU0NSSVBUSU9OCi1JZiBhIGZpbGUgZGVzY3JpcHRvciBp cyBncmFudGVkCitJZiBhIGZpbGUgZGVzY3JpcHRvciBpcyBncmFudGVkIHRoZQogLkR2IENB UF9GQ05UTAotY2FwYWJpbGl0eSByaWdodCwgbGlzdCBvZiBhbGxvd2VkCitjYXBhYmlsaXR5 IHJpZ2h0LCB0aGUgbGlzdCBvZiBhbGxvd2VkCiAuWHIgZmNudGwgMgogY29tbWFuZHMgY2Fu IGJlIHNlbGVjdGl2ZWx5IHJlZHVjZWQgKGJ1dCBuZXZlciBleHBhbmRlZCkgd2l0aCB0aGUK IC5GbiBjYXBfZmNudGxzX2xpbWl0CiBzeXN0ZW0gY2FsbC4KIC5QcAotQml0bWFzayBvZiBh bGxvd2VkIGZjbnRscyBjb21tYW5kcyBmb3IgYSBnaXZlbiBmaWxlIGRlc2NyaXB0b3IgY2Fu IGJlIG9idGFpbmVkCitBIGJpdG1hc2sgb2YgYWxsb3dlZCBmY250bHMgY29tbWFuZHMgZm9y IGEgZ2l2ZW4gZmlsZSBkZXNjcmlwdG9yIGNhbiBiZSBvYnRhaW5lZAogd2l0aCB0aGUKIC5G biBjYXBfZmNudGxzX2dldAogc3lzdGVtIGNhbGwuCkBAIC04OSwxMyArODksMTMgQEAgc3Vj Y2VlZHMgdW5sZXNzOgogLkl0IEJxIEVyIEVCQURGCiBUaGUKIC5GYSBmZAotYXJndW1lbnQg aXMgbm90IGEgdmFsaWQgYWN0aXZlIGRlc2NyaXB0b3IuCithcmd1bWVudCBpcyBub3QgYSB2 YWxpZCBkZXNjcmlwdG9yLgogLkl0IEJxIEVyIEVJTlZBTAogQW4gaW52YWxpZCBmbGFnIGhh cyBiZWVuIHBhc3NlZCBpbgogLkZhIGZjbnRscmlnaHRzIC4KIC5JdCBCcSBFciBFTk9UQ0FQ QUJMRQogLkZhIGZjbnRscmlnaHRzCi13b3VsZCBleHBhbmQgbGlzdCBvZiBhbGxvd2VkCit3 b3VsZCBleHBhbmQgdGhlIGxpc3Qgb2YgYWxsb3dlZAogLlhyIGZjbnRsIDIKIGNvbW1hbmRz LgogLkVsCkBAIC0xMDYsMTEgKzEwNiwxMSBAQCBzdWNjZWVkcyB1bmxlc3M6CiAuSXQgQnEg RXIgRUJBREYKIFRoZQogLkZhIGZkCi1hcmd1bWVudCBpcyBub3QgYSB2YWxpZCBhY3RpdmUg ZGVzY3JpcHRvci4KK2FyZ3VtZW50IGlzIG5vdCBhIHZhbGlkIGRlc2NyaXB0b3IuCiAuSXQg QnEgRXIgRUZBVUxUCiBUaGUKIC5GYSBmY250bHJpZ2h0c3AKLWFyZ3VtZW50IHBvaW50cyBh dCBpbnZhbGlkIGFkZHJlc3MuCithcmd1bWVudCBwb2ludHMgYXQgYW4gaW52YWxpZCBhZGRy ZXNzLgogLkVsCiAuU2ggU0VFIEFMU08KIC5YciBjYXBfaW9jdGxzX2xpbWl0IDIgLApkaWZm IC0tZ2l0IGEvbGliL2xpYmMvc3lzL2NhcF9pb2N0bHNfbGltaXQuMiBiL2xpYi9saWJjL3N5 cy9jYXBfaW9jdGxzX2xpbWl0LjIKaW5kZXggMzRhOWJmZi4uZGU1MjRkNyAxMDA2NDQKLS0t IGEvbGliL2xpYmMvc3lzL2NhcF9pb2N0bHNfbGltaXQuMgorKysgYi9saWIvbGliYy9zeXMv Y2FwX2lvY3Rsc19saW1pdC4yCkBAIC00NCw5ICs0NCw5IEBACiAuRnQgc3NpemVfdAogLkZu IGNhcF9pb2N0bHNfZ2V0ICJpbnQgZmQiICJ1bnNpZ25lZCBsb25nICpjbWRzIiAic2l6ZV90 IG1heGNtZHMiCiAuU2ggREVTQ1JJUFRJT04KLUlmIGEgZmlsZSBkZXNjcmlwdG9yIGlzIGdy YW50ZWQKK0lmIGEgZmlsZSBkZXNjcmlwdG9yIGlzIGdyYW50ZWQgdGhlCiAuRHYgQ0FQX0lP Q1RMCi1jYXBhYmlsaXR5IHJpZ2h0LCBsaXN0IG9mIGFsbG93ZWQKK2NhcGFiaWxpdHkgcmln aHQsIHRoZSBsaXN0IG9mIGFsbG93ZWQKIC5YciBpb2N0bCAyCiBjb21tYW5kcyBjYW4gYmUg c2VsZWN0aXZlbHkgcmVkdWNlZCAoYnV0IG5ldmVyIGV4cGFuZGVkKSB3aXRoIHRoZQogLkZu IGNhcF9pb2N0bHNfbGltaXQKQEAgLTYyLDIxICs2MiwyMSBAQCBUaGVyZSBtaWdodCBiZSB1 cCB0bwogLlZhIDI1NgogZWxlbWVudHMgaW4gdGhlIGFycmF5LgogLlBwCi1MaXN0IG9mIGFs bG93ZWQgaW9jdGwgY29tbWFuZHMgZm9yIGEgZ2l2ZW4gZmlsZSBkZXNjcmlwdG9yIGNhbiBi ZSBvYnRhaW5lZAorVGhlIGxpc3Qgb2YgYWxsb3dlZCBpb2N0bCBjb21tYW5kcyBmb3IgYSBn aXZlbiBmaWxlIGRlc2NyaXB0b3IgY2FuIGJlIG9idGFpbmVkCiB3aXRoIHRoZQogLkZuIGNh cF9pb2N0bHNfZ2V0CiBzeXN0ZW0gY2FsbC4KIFRoZQogLkZhIGNtZHMKLWFyZ3VtZW50cyBw b2ludHMgYXQgdGhlIG1lbW9yeSB0aGF0IGNhbiBob2xkIHVwIHRvCithcmd1bWVudCBwb2lu dHMgYXQgbWVtb3J5IHRoYXQgY2FuIGhvbGQgdXAgdG8KIC5GYSBtYXhjbWRzCiB2YWx1ZXMu Ci1UaGUgZnVuY3Rpb24gcG9wdWxhdGVzIHByb3ZpZGVkIGJ1ZmZlciB3aXRoIHVwIHRvCitU aGUgZnVuY3Rpb24gcG9wdWxhdGVzIHRoZSBwcm92aWRlZCBidWZmZXIgd2l0aCB1cCB0bwog LkZhIG1heGNtZHMKLWVsZW1lbnRzLCBidXQgYWx3YXlzIHJldHVybnMgdG90YWwgbnVtYmVy IG9mIGlvY3RsIGNvbW1hbmRzIGFsbG93ZWQgZm9yIHRoZQorZWxlbWVudHMsIGJ1dCBhbHdh eXMgcmV0dXJucyB0aGUgdG90YWwgbnVtYmVyIG9mIGlvY3RsIGNvbW1hbmRzIGFsbG93ZWQg Zm9yIHRoZQogZ2l2ZW4gZmlsZSBkZXNjcmlwdG9yLgotVG90YWwgbnVtYmVyIG9mIGlvY3Rs cyBjb21tYW5kcyBmb3IgdGhlIGdpdmVuIGZpbGUgZGVzY3JpcHRvciBjYW4gYmUgb2J0YWlu ZWQKLWJ5IHBhc3NpbmcKK1RoZSB0b3RhbCBudW1iZXIgb2YgaW9jdGxzIGNvbW1hbmRzIGZv ciB0aGUgZ2l2ZW4gZmlsZSBkZXNjcmlwdG9yIGNhbiBiZQorb2J0YWluZWQgYnkgcGFzc2lu ZwogLkR2IE5VTEwgYXMgdGhlCiAuRmEgY21kcwogYXJndW1lbnQgYW5kCkBAIC0xMTQsMTEg KzExNCwxMSBAQCBzdWNjZWVkcyB1bmxlc3M6CiAuSXQgQnEgRXIgRUJBREYKIFRoZQogLkZh IGZkCi1hcmd1bWVudCBpcyBub3QgYSB2YWxpZCBhY3RpdmUgZGVzY3JpcHRvci4KK2FyZ3Vt ZW50IGlzIG5vdCBhIHZhbGlkIGRlc2NyaXB0b3IuCiAuSXQgQnEgRXIgRUZBVUxUCiBUaGUK IC5GYSBjbWRzCi1hcmd1bWVudCBwb2ludHMgYXQgaW52YWxpZCBhZGRyZXNzLgorYXJndW1l bnQgcG9pbnRzIGF0IGFuIGludmFsaWQgYWRkcmVzcy4KIC5JdCBCcSBFciBFSU5WQUwKIFRo ZQogLkZhIG5jbWRzCkBAIC0xMjYsNyArMTI2LDcgQEAgYXJndW1lbnQgaXMgZ3JlYXRlciB0 aGFuCiAuVmEgMjU2IC4KIC5JdCBCcSBFciBFTk9UQ0FQQUJMRQogLkZhIGNtZHMKLXdvdWxk IGV4cGFuZCBsaXN0IG9mIGFsbG93ZWQKK3dvdWxkIGV4cGFuZCB0aGUgbGlzdCBvZiBhbGxv d2VkCiAuWHIgaW9jdGwgMgogY29tbWFuZHMuCiAuRWwKQEAgLTEzNyw3ICsxMzcsNyBAQCBz dWNjZWVkcyB1bmxlc3M6CiAuSXQgQnEgRXIgRUJBREYKIFRoZQogLkZhIGZkCi1hcmd1bWVu dCBpcyBub3QgYSB2YWxpZCBhY3RpdmUgZGVzY3JpcHRvci4KK2FyZ3VtZW50IGlzIG5vdCBh IHZhbGlkIGRlc2NyaXB0b3IuCiAuSXQgQnEgRXIgRUZBVUxUCiBUaGUKIC5GYSBjbWRzCmRp ZmYgLS1naXQgYS9saWIvbGliYy9zeXMvY2FwX3JpZ2h0c19saW1pdC4yIGIvbGliL2xpYmMv c3lzL2NhcF9yaWdodHNfbGltaXQuMgppbmRleCAyZTgzZWEwLi5lMmZmMTM0IDEwMDY0NAot LS0gYS9saWIvbGliYy9zeXMvY2FwX3JpZ2h0c19saW1pdC4yCisrKyBiL2xpYi9saWJjL3N5 cy9jYXBfcmlnaHRzX2xpbWl0LjIKQEAgLTY4LDcgKzY4LDcgQEAgT25jZSBjYXBhYmlsaXR5 IHJpZ2h0cyBhcmUgcmVkdWNlZCwgb3BlcmF0aW9ucyBvbiB0aGUgZmlsZSBkZXNjcmlwdG9y IHdpbGwgYmUKIGxpbWl0ZWQgdG8gdGhvc2UgcGVybWl0dGVkIGJ5CiAuRmEgcmlnaHRzIC4K IC5QcAotQml0bWFzayBvZiBjYXBhYmlsaXR5IHJpZ2h0cyBhc3NpZ25lZCB0byBhIGZpbGUg ZGVzY3JpcHRvciBjYW4gYmUgb2J0YWluZWQgd2l0aAorQSBiaXRtYXNrIG9mIGNhcGFiaWxp dHkgcmlnaHRzIGFzc2lnbmVkIHRvIGEgZmlsZSBkZXNjcmlwdG9yIGNhbiBiZSBvYnRhaW5l ZCB3aXRoCiB0aGUKIC5GbiBjYXBfcmlnaHRzX2dldAogc3lzdGVtIGNhbGwuCkBAIC0xNzgs NyArMTc4LDcgQEAgTm90ZSB0aGF0IG9ubHkgdGhlCiBhbmQKIC5EdiBGX1NFVE9XTgogY29t bWFuZHMgcmVxdWlyZSB0aGlzIGNhcGFiaWxpdHkgcmlnaHQuCi1BbHNvIG5vdGUgdGhhdCB0 aGUgbGlzdCBvZiBwZXJtaXR0ZWQgY29tbWFuZHMgY2FuIGJlIGZ1dGhlciBsaW1pdGVkIHdp dGggdGhlCitBbHNvIG5vdGUgdGhhdCB0aGUgbGlzdCBvZiBwZXJtaXR0ZWQgY29tbWFuZHMg Y2FuIGJlIGZ1cnRoZXIgbGltaXRlZCB3aXRoIHRoZQogLlhyIGNhcF9mY250bHNfbGltaXQg Mgogc3lzdGVtIGNhbGwuCiAuSXQgRHYgQ0FQX0ZMT0NLCkBAIC0yNTQsNyArMjU0LDcgQEAg UGVybWl0CiAuWHIgaW9jdGwgMiAuCiBCZSBhd2FyZSB0aGF0IHRoaXMgc3lzdGVtIGNhbGwg aGFzIGVub3Jtb3VzIHNjb3BlLCBpbmNsdWRpbmcgcG90ZW50aWFsbHkKIGdsb2JhbCBzY29w ZSBmb3Igc29tZSBvYmplY3RzLgotVGhlIGxpc3Qgb2YgcGVybWl0dGVkIGlvY3RsIGNvbW1h bmRzIGNhbiBiZSBmdXRoZXIgbGltaXRlZCB3aXRoIHRoZQorVGhlIGxpc3Qgb2YgcGVybWl0 dGVkIGlvY3RsIGNvbW1hbmRzIGNhbiBiZSBmdXJ0aGVyIGxpbWl0ZWQgd2l0aCB0aGUKIC5Y ciBjYXBfaW9jdGxzX2xpbWl0IDIKIHN5c3RlbSBjYWxsLgogLlwiIFhYWFBKRDogRG9lc24n dCBleGlzdCBhbnltb3JlLgpAQCAtNDcwLDcgKzQ3MCw3IEBAIHdpdGggdGhlCiAuRHYgT19X Uk9OTFkKIGZsYWcsIGJ1dCB3aXRob3V0IHRoZQogLkR2IE9fQVBQRU5ECi1mbGFnCitmbGFn LAogLkR2IENBUF9TRUVLCiBpcyBhbHNvIHJlcXVpcmVkLgogLkVsCkBAIC01MDMsNyArNTAz LDcgQEAgYXJndW1lbnQgaXMgbm90IGEgdmFsaWQgYWN0aXZlIGRlc2NyaXB0b3IuCiAuSXQg QnEgRXIgRUZBVUxUCiBUaGUKIC5GYSByaWdodHNwCi1hcmd1bWVudCBwb2ludHMgYXQgaW52 YWxpZCBhZGRyZXNzLgorYXJndW1lbnQgcG9pbnRzIGF0IGFuIGludmFsaWQgYWRkcmVzcy4K IC5FbAogLlNoIFNFRSBBTFNPCiAuWHIgYWNjZXB0IDIgLApkaWZmIC0tZ2l0IGEvc3lzL3N5 cy9jYXBhYmlsaXR5LmggYi9zeXMvc3lzL2NhcGFiaWxpdHkuaAppbmRleCA5ZWVkNGQxLi4x MzBkMjAwIDEwMDY0NAotLS0gYS9zeXMvc3lzL2NhcGFiaWxpdHkuaAorKysgYi9zeXMvc3lz L2NhcGFiaWxpdHkuaApAQCAtMjY3LDcgKzI2Nyw3IEBAIGludAljYXBfZW50ZXIodm9pZCk7 CiAKIC8qCiAgKiBBcmUgd2Ugc2FuZGJveGVkIChpbiBjYXBhYmlsaXR5IG1vZGUpPwotICog VGhpcyBpcyBsaWJjIHdyYXBwZXIgYXJvdW5kIGNhcF9nZXRtb2RlKDIpIHN5c3RlbSBjYWxs LgorICogVGhpcyBpcyBhIGxpYmMgd3JhcHBlciBhcm91bmQgdGhlIGNhcF9nZXRtb2RlKDIp IHN5c3RlbSBjYWxsLgogICovCiBfQm9vbAljYXBfc2FuZGJveGVkKHZvaWQpOwogCkBAIC0y ODksNyArMjg5LDcgQEAgaW50IGNhcF9yaWdodHNfZ2V0KGludCBmZCwgY2FwX3JpZ2h0c190 ICpyaWdodHNwKTsKICAqLwogaW50IGNhcF9pb2N0bHNfbGltaXQoaW50IGZkLCBjb25zdCB1 bnNpZ25lZCBsb25nICpjbWRzLCBzaXplX3QgbmNtZHMpOwogLyoKLSAqIFJldHVybnMgYXJy YXkgb2YgYWxsb3dlZCBpb2N0bHMgZm9yIHRoZSBnaXZlbiBkZXNjcmlwdG9ycy4KKyAqIFJl dHVybnMgYXJyYXkgb2YgYWxsb3dlZCBpb2N0bHMgZm9yIHRoZSBnaXZlbiBkZXNjcmlwdG9y LgogICogSWYgYWxsIGlvY3RscyBhcmUgYWxsb3dlZCwgdGhlIGNtZHMgYXJyYXkgaXMgbm90 IHBvcHVsYXRlZCBhbmQKICAqIHRoZSBmdW5jdGlvbiByZXR1cm5zIElOVF9NQVguCiAgKi8K LS0gCjEuOC4xLjMKCg== --------------060105070608040709090402 Content-Type: text/plain; charset=UTF-8; name="0019-Sort-Xr.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="0019-Sort-Xr.patch" RnJvbSAyYjhhMTU0MzEyZjY5MjkxMmZjOTBiYzJhY2Q4ZTU1YWIxZmM0YmE0IE1vbiBTZXAg MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBDaHJpc3RvcGggTWFsbG9uIDxjaHJpc3RvcGgubWFs bG9uQGdteC5kZT4KRGF0ZTogU3VuLCAyNCBGZWIgMjAxMyAxNDowMDozMSArMDEwMApTdWJq ZWN0OiBbUEFUQ0ggMTkvMjRdIFNvcnQgWHIuCgotLS0KIGxpYi9saWJjL3N5cy9jYXBfcmln aHRzX2xpbWl0LjIgfCAyICstCiAxIGZpbGUgY2hhbmdlZCwgMSBpbnNlcnRpb24oKyksIDEg ZGVsZXRpb24oLSkKCmRpZmYgLS1naXQgYS9saWIvbGliYy9zeXMvY2FwX3JpZ2h0c19saW1p dC4yIGIvbGliL2xpYmMvc3lzL2NhcF9yaWdodHNfbGltaXQuMgppbmRleCBlMmZmMTM0Li5k OGQ4Nzc3IDEwMDY0NAotLS0gYS9saWIvbGliYy9zeXMvY2FwX3JpZ2h0c19saW1pdC4yCisr KyBiL2xpYi9saWJjL3N5cy9jYXBfcmlnaHRzX2xpbWl0LjIKQEAgLTU0Niw4ICs1NDYsOCBA QCBhcmd1bWVudCBwb2ludHMgYXQgYW4gaW52YWxpZCBhZGRyZXNzLgogLlhyIG1xX29wZW4g MiAsCiAuWHIgb3BlbiAyICwKIC5YciBvcGVuYXQgMiAsCi0uWHIgcGRnZXRwaWQgMiAsCiAu WHIgcGRmb3JrIDIgLAorLlhyIHBkZ2V0cGlkIDIgLAogLlhyIHBka2lsbCAyICwKIC5YciBw ZHdhaXQ0IDIgLAogLlhyIHBpcGUgMiAsCi0tIAoxLjguMS4zCgo= --------------060105070608040709090402 Content-Type: text/plain; charset=UTF-8; name="0020-Avoid-comparing-signed-with-unsigned-values.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="0020-Avoid-comparing-signed-with-unsigned-values.patch" RnJvbSA0MmFhYWExNGM1YzFhNWQ5NjUwM2E4OGEzODE5MDlkNmMzMjU0NzI3IE1vbiBTZXAg MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBDaHJpc3RvcGggTWFsbG9uIDxjaHJpc3RvcGgubWFs bG9uQGdteC5kZT4KRGF0ZTogU3VuLCAyNCBGZWIgMjAxMyAxNDowNDozNiArMDEwMApTdWJq ZWN0OiBbUEFUQ0ggMjAvMjRdIEF2b2lkIGNvbXBhcmluZyBzaWduZWQgd2l0aCB1bnNpZ25l ZCB2YWx1ZXMuCgotLS0KIHN5cy9mcy9uZnNzZXJ2ZXIvbmZzX25mc2Rwb3J0LmMgfCAyICst CiBzeXMva2Vybi9zeXNfY2FwYWJpbGl0eS5jICAgICAgIHwgNyArKysrLS0tCiAyIGZpbGVz IGNoYW5nZWQsIDUgaW5zZXJ0aW9ucygrKSwgNCBkZWxldGlvbnMoLSkKCmRpZmYgLS1naXQg YS9zeXMvZnMvbmZzc2VydmVyL25mc19uZnNkcG9ydC5jIGIvc3lzL2ZzL25mc3NlcnZlci9u ZnNfbmZzZHBvcnQuYwppbmRleCA4ODBmOTY1Li42OWY1NjI5IDEwMDY0NAotLS0gYS9zeXMv ZnMvbmZzc2VydmVyL25mc19uZnNkcG9ydC5jCisrKyBiL3N5cy9mcy9uZnNzZXJ2ZXIvbmZz X25mc2Rwb3J0LmMKQEAgLTI3NzUsNyArMjc3NSw3IEBAIGZwX2dldGZ2cChzdHJ1Y3QgdGhy ZWFkICpwLCBpbnQgZmQsIHN0cnVjdCBmaWxlICoqZnBwLCBzdHJ1Y3Qgdm5vZGUgKip2cHAp CiAJaW50IGVycm9yID0gMDsKIAogCWZkcCA9IHAtPnRkX3Byb2MtPnBfZmQ7Ci0JaWYgKCh1 X2ludClmZCA+PSBmZHAtPmZkX25maWxlcyB8fAorCWlmIChmZCA8IDAgfHwgZmRwLT5mZF9u ZmlsZXMgPD0gZmQgfHwKIAkgICAgKGZwID0gZmRwLT5mZF9vZmlsZXNbZmRdLmZkZV9maWxl KSA9PSBOVUxMKSB7CiAJCWVycm9yID0gRUJBREY7CiAJCWdvdG8gb3V0OwpkaWZmIC0tZ2l0 IGEvc3lzL2tlcm4vc3lzX2NhcGFiaWxpdHkuYyBiL3N5cy9rZXJuL3N5c19jYXBhYmlsaXR5 LmMKaW5kZXggZTg3YTRlNS4uZTM2MjJiMCAxMDA2NDQKLS0tIGEvc3lzL2tlcm4vc3lzX2Nh cGFiaWxpdHkuYworKysgYi9zeXMva2Vybi9zeXNfY2FwYWJpbGl0eS5jCkBAIC0yNzQsNyAr Mjc0LDcgQEAgY2FwX2lvY3RsX2NoZWNrKHN0cnVjdCBmaWxlZGVzYyAqZmRwLCBpbnQgZmQs IHVfbG9uZyBjbWQpCiB7CiAJdV9sb25nICpjbWRzOwogCXNzaXplX3QgbmNtZHM7Ci0JdV9p bnQgaTsKKwlzc2l6ZV90IGk7CiAKIAlGSUxFREVTQ19MT0NLX0FTU0VSVChmZHApOwogCUtB U1NFUlQoZmQgPj0gMCAmJiBmZCA8IGZkcC0+ZmRfbmZpbGVzLApAQCAtMzAyLDEyICszMDIs MTMgQEAgY2FwX2lvY3RsX2xpbWl0X2NoZWNrKHN0cnVjdCBmaWxlZGVzYyAqZmRwLCBpbnQg ZmQsIGNvbnN0IHVfbG9uZyAqY21kcywKIHsKIAl1X2xvbmcgKm9jbWRzOwogCXNzaXplX3Qg b25jbWRzOwotCXVfaW50IGksIGo7CisJc2l6ZV90IGk7CisJc3NpemVfdCBqOwogCiAJb25j bWRzID0gZmRwLT5mZF9vZmlsZXNbZmRdLmZkZV9uaW9jdGxzOwogCWlmIChvbmNtZHMgPT0g LTEpCiAJCXJldHVybiAoMCk7Ci0JaWYgKG9uY21kcyA8IG5jbWRzKQorCWlmICgoc2l6ZV90 KW9uY21kcyA8IG5jbWRzKQogCQlyZXR1cm4gKEVOT1RDQVBBQkxFKTsKIAogCW9jbWRzID0g ZmRwLT5mZF9vZmlsZXNbZmRdLmZkZV9pb2N0bHM7Ci0tIAoxLjguMS4zCgo= --------------060105070608040709090402 Content-Type: text/plain; charset=UTF-8; name="0021-For-readability-simplify-if-x-y-a-else-y-b-with-long.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename*0="0021-For-readability-simplify-if-x-y-a-else-y-b-with-long.pa"; filename*1="tch" RnJvbSBhMDUxNDRlMTk0MTFkMmIzZmM4NzE2ZTcyZWYyZmFkN2NjOTQ0OWFlIE1vbiBTZXAg MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBDaHJpc3RvcGggTWFsbG9uIDxjaHJpc3RvcGgubWFs bG9uQGdteC5kZT4KRGF0ZTogU3VuLCAyNCBGZWIgMjAxMyAxNTowOToxNiArMDEwMApTdWJq ZWN0OiBbUEFUQ0ggMjEvMjRdIEZvciByZWFkYWJpbGl0eSBzaW1wbGlmeSBpZiAoeCkgeSA9 IGE7IGVsc2UgeSA9IGI7IHdpdGgKIGxvbmcgeSB0byB5ID0geCA/IGEgOiBiLgoKLS0tCiBz eXMva2Vybi9rZXJuX2Rlc2NyaXAuYyAgIHwgMTAgKysrLS0tLS0tLQogc3lzL2tlcm4vc3lz X2NhcGFiaWxpdHkuYyB8ICA2ICsrLS0tLQogMiBmaWxlcyBjaGFuZ2VkLCA1IGluc2VydGlv bnMoKyksIDExIGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL3N5cy9rZXJuL2tlcm5fZGVz Y3JpcC5jIGIvc3lzL2tlcm4va2Vybl9kZXNjcmlwLmMKaW5kZXggNjEyZDUxYS4uMzBkYWMw NCAxMDA2NDQKLS0tIGEvc3lzL2tlcm4va2Vybl9kZXNjcmlwLmMKKysrIGIvc3lzL2tlcm4v a2Vybl9kZXNjcmlwLmMKQEAgLTg0MiwxMyArODQyLDkgQEAgZG9fZHVwKHN0cnVjdCB0aHJl YWQgKnRkLCBpbnQgZmxhZ3MsIGludCBvbGQsIGludCBuZXcsCiAJZmRwLT5mZF9vZmlsZXNb bmV3XSA9IGZkcC0+ZmRfb2ZpbGVzW29sZF07CiAJZmlsZWNhcHNfY29weSgmZmRwLT5mZF9v ZmlsZXNbb2xkXS5mZGVfY2FwcywKIAkgICAgJmZkcC0+ZmRfb2ZpbGVzW25ld10uZmRlX2Nh cHMpOwotCWlmICgoZmxhZ3MgJiBEVVBfQ0xPRVhFQykgIT0gMCkgewotCQlmZHAtPmZkX29m aWxlc1tuZXddLmZkZV9mbGFncyA9Ci0JCSAgICBmZHAtPmZkX29maWxlc1tvbGRdLmZkZV9m bGFncyB8IFVGX0VYQ0xPU0U7Ci0JfSBlbHNlIHsKLQkJZmRwLT5mZF9vZmlsZXNbbmV3XS5m ZGVfZmxhZ3MgPQotCQkgICAgZmRwLT5mZF9vZmlsZXNbb2xkXS5mZGVfZmxhZ3MgJiB+VUZf RVhDTE9TRTsKLQl9CisJZmRwLT5mZF9vZmlsZXNbbmV3XS5mZGVfZmxhZ3MgPSBmbGFncyAm IERVUF9DTE9FWEVDID8KKwkgICAgZmRwLT5mZF9vZmlsZXNbb2xkXS5mZGVfZmxhZ3MgfCAg VUZfRVhDTE9TRSA6CisJICAgIGZkcC0+ZmRfb2ZpbGVzW29sZF0uZmRlX2ZsYWdzICYgflVG X0VYQ0xPU0U7CiAJaWYgKG5ldyA+IGZkcC0+ZmRfbGFzdGZpbGUpCiAJCWZkcC0+ZmRfbGFz dGZpbGUgPSBuZXc7CiAJKnJldHZhbCA9IG5ldzsKZGlmZiAtLWdpdCBhL3N5cy9rZXJuL3N5 c19jYXBhYmlsaXR5LmMgYi9zeXMva2Vybi9zeXNfY2FwYWJpbGl0eS5jCmluZGV4IGUzNjIy YjAuLjIzMDY4MTEgMTAwNjQ0Ci0tLSBhL3N5cy9rZXJuL3N5c19jYXBhYmlsaXR5LmMKKysr IGIvc3lzL2tlcm4vc3lzX2NhcGFiaWxpdHkuYwpAQCAtNDA5LDEwICs0MDksOCBAQCBzeXNf Y2FwX2lvY3Rsc19nZXQoc3RydWN0IHRocmVhZCAqdGQsIHN0cnVjdCBjYXBfaW9jdGxzX2dl dF9hcmdzICp1YXApCiAJCWlmIChlcnJvciAhPSAwKQogCQkJZ290byBvdXQ7CiAJfQotCWlm IChmZGVwLT5mZGVfbmlvY3RscyA9PSAtMSkKLQkJdGQtPnRkX3JldHZhbFswXSA9IElOVF9N QVg7Ci0JZWxzZQotCQl0ZC0+dGRfcmV0dmFsWzBdID0gZmRlcC0+ZmRlX25pb2N0bHM7CisJ dGQtPnRkX3JldHZhbFswXSA9CisJICAgIGZkZXAtPmZkZV9uaW9jdGxzICE9IC0xID8gZmRl cC0+ZmRlX25pb2N0bHMgOiBJTlRfTUFYOwogCWVycm9yID0gMDsKIAogb3V0OgotLSAKMS44 LjEuMwoK --------------060105070608040709090402 Content-Type: text/plain; charset=UTF-8; name="0022-Unify-and-simplify-bitset-inclusion-tests.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="0022-Unify-and-simplify-bitset-inclusion-tests.patch" RnJvbSAxMjU4OTUxZWYzY2RiOGI4NjI0ZTZhNzAzMjAzNmUwZTVlMGFjOGM2IE1vbiBTZXAg MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBDaHJpc3RvcGggTWFsbG9uIDxjaHJpc3RvcGgubWFs bG9uQGdteC5kZT4KRGF0ZTogU3VuLCAyNCBGZWIgMjAxMyAxNToyMzoxNSArMDEwMApTdWJq ZWN0OiBbUEFUQ0ggMjIvMjRdIFVuaWZ5IGFuZCBzaW1wbGlmeSBiaXRzZXQgaW5jbHVzaW9u IHRlc3RzLgoKLSAoaGF2ZSB8IG5lZWQpICE9IGhhdmUgbG9va3MgbGlrZSBhIHR5cG86IHNo b3VsZG4ndCB0aGUgfCBiZSBhICY/LgotIHNvbWUgcGxhY2VzIHVzZWQgKGhhdmUgfCBuZWVk KSAhPSBoYXZlLCBvdGhlcnMgKGhhdmUgJiBuZWVkKSA9PSBuZWVkLgotIChuZWVkICYgfmhh dmUpICE9IDAgLS0gbmVlZCBhbmQgbm90IGhhdmUgLS0gaXMgZWFzaWVyIHRvIGNvbXByZWhl bmQuCi0gQXZvaWQgZHVwbGljYXRpb24sIGVzcGVjaWFsbHkgd2hlbiB0aGUgZHVwbGljYXRl ZCBzdWJleHByZXNzaW9uIGlzIGxvbmcuCi0tLQogc3lzL2tlcm4va2Vybl9kZXNjcmlwLmMg ICAgICAgICAgIHwgIDQgKystLQogc3lzL2tlcm4vc3lzX2NhcGFiaWxpdHkuYyAgICAgICAg IHwgMTEgKysrKystLS0tLS0KIHVzci5iaW4vcHJvY3N0YXQvcHJvY3N0YXRfZmlsZXMuYyB8 ICA0ICsrLS0KIDMgZmlsZXMgY2hhbmdlZCwgOSBpbnNlcnRpb25zKCspLCAxMCBkZWxldGlv bnMoLSkKCmRpZmYgLS1naXQgYS9zeXMva2Vybi9rZXJuX2Rlc2NyaXAuYyBiL3N5cy9rZXJu L2tlcm5fZGVzY3JpcC5jCmluZGV4IDMwZGFjMDQuLjY0MTc2Y2EgMTAwNjQ0Ci0tLSBhL3N5 cy9rZXJuL2tlcm5fZGVzY3JpcC5jCisrKyBiL3N5cy9rZXJuL2tlcm5fZGVzY3JpcC5jCkBA IC0xNDIyLDkgKzE0MjIsOSBAQCBzdGF0aWMgdm9pZAogZmlsZWNhcHNfdmFsaWRhdGUoY29u c3Qgc3RydWN0IGZpbGVjYXBzICpmY2FwcywgY29uc3QgY2hhciAqZnVuYykKIHsKIAotCUtB U1NFUlQoKGZjYXBzLT5mY19yaWdodHMgfCBDQVBfTUFTS19WQUxJRCkgPT0gQ0FQX01BU0tf VkFMSUQsCisJS0FTU0VSVCgoZmNhcHMtPmZjX3JpZ2h0cyAmIH5DQVBfTUFTS19WQUxJRCkg PT0gMCwKIAkgICAgKCIlczogaW52YWxpZCByaWdodHMiLCBmdW5jKSk7Ci0JS0FTU0VSVCgo ZmNhcHMtPmZjX2ZjbnRscyB8IENBUF9GQ05UTF9BTEwpID09IENBUF9GQ05UTF9BTEwsCisJ S0FTU0VSVCgoZmNhcHMtPmZjX2ZjbnRscyAmIH5DQVBfRkNOVExfQUxMKSA9PSAwLAogCSAg ICAoIiVzOiBpbnZhbGlkIGZjbnRscyIsIGZ1bmMpKTsKIAlLQVNTRVJUKGZjYXBzLT5mY19m Y250bHMgPT0gMCB8fCAoZmNhcHMtPmZjX3JpZ2h0cyAmIENBUF9GQ05UTCkgIT0gMCwKIAkg ICAgKCIlczogZmNudGxzIHdpdGhvdXQgQ0FQX0ZDTlRMIiwgZnVuYykpOwpkaWZmIC0tZ2l0 IGEvc3lzL2tlcm4vc3lzX2NhcGFiaWxpdHkuYyBiL3N5cy9rZXJuL3N5c19jYXBhYmlsaXR5 LmMKaW5kZXggMjMwNjgxMS4uZDA2OTE4YyAxMDA2NDQKLS0tIGEvc3lzL2tlcm4vc3lzX2Nh cGFiaWxpdHkuYworKysgYi9zeXMva2Vybi9zeXNfY2FwYWJpbGl0eS5jCkBAIC0xNDgsNyAr MTQ4LDcgQEAgc3RhdGljIGlubGluZSBpbnQKIF9jYXBfY2hlY2soY2FwX3JpZ2h0c190IGhh dmUsIGNhcF9yaWdodHNfdCBuZWVkLCBlbnVtIGt0cl9jYXBfZmFpbF90eXBlIHR5cGUpCiB7 CiAKLQlpZiAoKGhhdmUgfCBuZWVkKSAhPSBoYXZlKSB7CisJaWYgKChuZWVkICYgfmhhdmUp ICE9IDApIHsKICNpZmRlZiBLVFJBQ0UKIAkJaWYgKEtUUlBPSU5UKGN1cnRocmVhZCwgS1RS X0NBUEZBSUwpKQogCQkJa3RyY2FwZmFpbCh0eXBlLCBuZWVkLCBoYXZlKTsKQEAgLTIxNSw3 ICsyMTUsNyBAQCBzeXNfY2FwX3JpZ2h0c19saW1pdChzdHJ1Y3QgdGhyZWFkICp0ZCwgc3Ry dWN0IGNhcF9yaWdodHNfbGltaXRfYXJncyAqdWFwKQogCUFVRElUX0FSR19GRChmZCk7CiAJ QVVESVRfQVJHX1JJR0hUUyhyaWdodHMpOwogCi0JaWYgKChyaWdodHMgfCBDQVBfQUxMKSAh PSBDQVBfQUxMKQorCWlmICgocmlnaHRzICYgfkNBUF9BTEwpICE9IDApCiAJCXJldHVybiAo RUlOVkFMKTsKIAogCWZkcCA9IHRkLT50ZF9wcm9jLT5wX2ZkOwpAQCAtNDUyLDcgKzQ1Miw3 IEBAIHN5c19jYXBfZmNudGxzX2xpbWl0KHN0cnVjdCB0aHJlYWQgKnRkLCBzdHJ1Y3QgY2Fw X2ZjbnRsc19saW1pdF9hcmdzICp1YXApCiAJQVVESVRfQVJHX0ZEKGZkKTsKIAlBVURJVF9B UkdfRkNOVExfUklHSFRTKGZjbnRscmlnaHRzKTsKIAotCWlmICgoZmNudGxyaWdodHMgfCBD QVBfRkNOVExfQUxMKSAhPSBDQVBfRkNOVExfQUxMKQorCWlmICgoZmNudGxyaWdodHMgJiB+ Q0FQX0ZDTlRMX0FMTCkgIT0gMCkKIAkJcmV0dXJuIChFSU5WQUwpOwogCiAJZmRwID0gdGQt PnRkX3Byb2MtPnBfZmQ7CkBAIC00NjMsOCArNDYzLDcgQEAgc3lzX2NhcF9mY250bHNfbGlt aXQoc3RydWN0IHRocmVhZCAqdGQsIHN0cnVjdCBjYXBfZmNudGxzX2xpbWl0X2FyZ3MgKnVh cCkKIAkJcmV0dXJuIChFQkFERik7CiAJfQogCi0JaWYgKChmZHAtPmZkX29maWxlc1tmZF0u ZmRlX2ZjbnRscyB8IGZjbnRscmlnaHRzKSAhPQotCSAgICBmZHAtPmZkX29maWxlc1tmZF0u ZmRlX2ZjbnRscykgeworCWlmICgoZmNudGxyaWdodHMgJiB+ZmRwLT5mZF9vZmlsZXNbZmRd LmZkZV9mY250bHMpICE9IDApIHsKIAkJRklMRURFU0NfWFVOTE9DSyhmZHApOwogCQlyZXR1 cm4gKEVOT1RDQVBBQkxFKTsKIAl9CkBAIC01MTUsNyArNTE0LDcgQEAgc3lzX2NhcF9uZXco c3RydWN0IHRocmVhZCAqdGQsIHN0cnVjdCBjYXBfbmV3X2FyZ3MgKnVhcCkKIAlBVURJVF9B UkdfRkQoZmQpOwogCUFVRElUX0FSR19SSUdIVFMocmlnaHRzKTsKIAotCWlmICgocmlnaHRz IHwgQ0FQX0FMTCkgIT0gQ0FQX0FMTCkKKwlpZiAoKHJpZ2h0cyAmIH5DQVBfQUxMKSAhPSAw KQogCQlyZXR1cm4gKEVJTlZBTCk7CiAKIAlmZHAgPSB0ZC0+dGRfcHJvYy0+cF9mZDsKZGlm ZiAtLWdpdCBhL3Vzci5iaW4vcHJvY3N0YXQvcHJvY3N0YXRfZmlsZXMuYyBiL3Vzci5iaW4v cHJvY3N0YXQvcHJvY3N0YXRfZmlsZXMuYwppbmRleCBlZWZjNWI3Li4xNmRhYjBiIDEwMDY0 NAotLS0gYS91c3IuYmluL3Byb2NzdGF0L3Byb2NzdGF0X2ZpbGVzLmMKKysrIGIvdXNyLmJp bi9wcm9jc3RhdC9wcm9jc3RhdF9maWxlcy5jCkBAIC0yNDMsNyArMjQzLDcgQEAgd2lkdGhf Y2FwYWJpbGl0eShjYXBfcmlnaHRzX3QgcmlnaHRzKQogCWNvdW50ID0gMDsKIAl3aWR0aCA9 IDA7CiAJZm9yIChpID0gMDsgaSA8IGNhcF9kZXNjX2NvdW50OyBpKyspIHsKLQkJaWYgKChy aWdodHMgJiBjYXBfZGVzY1tpXS5jZF9yaWdodCkgPT0gY2FwX2Rlc2NbaV0uY2RfcmlnaHQp IHsKKwkJaWYgKChjYXBfZGVzY1tpXS5jZF9yaWdodCAmIH5yaWdodHMpID09IDApIHsKIAkJ CXdpZHRoICs9IHN0cmxlbihjYXBfZGVzY1tpXS5jZF9kZXNjKTsKIAkJCWlmIChjb3VudCkK IAkJCQl3aWR0aCsrOwpAQCAtMjY3LDcgKzI2Nyw3IEBAIHByaW50X2NhcGFiaWxpdHkoY2Fw X3JpZ2h0c190IHJpZ2h0cywgdV9pbnQgY2Fwd2lkdGgpCiAJCQlwcmludGYoIi0iKTsKIAl9 CiAJZm9yIChpID0gMDsgaSA8IGNhcF9kZXNjX2NvdW50OyBpKyspIHsKLQkJaWYgKChyaWdo dHMgJiBjYXBfZGVzY1tpXS5jZF9yaWdodCkgPT0gY2FwX2Rlc2NbaV0uY2RfcmlnaHQpIHsK KwkJaWYgKChjYXBfZGVzY1tpXS5jZF9yaWdodCAmIH5yaWdodHMpID09IDApIHsKIAkJCXBy aW50ZigiJXMlcyIsIGNvdW50ID8gIiwiIDogIiIsIGNhcF9kZXNjW2ldLmNkX2Rlc2MpOwog CQkJd2lkdGggKz0gc3RybGVuKGNhcF9kZXNjW2ldLmNkX2Rlc2MpOwogCQkJaWYgKGNvdW50 KQotLSAKMS44LjEuMwoK --------------060105070608040709090402 Content-Type: text/plain; charset=UTF-8; name="0023-Simplify-assertion-condition-which-contains-a-duplic.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename*0="0023-Simplify-assertion-condition-which-contains-a-duplic.pa"; filename*1="tch" RnJvbSA0ZDcyMWI3YWE5MDkwOTFmYzcwNWNjOGY4MjJhMTNkYTY5ZTE5NTRjIE1vbiBTZXAg MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBDaHJpc3RvcGggTWFsbG9uIDxjaHJpc3RvcGgubWFs bG9uQGdteC5kZT4KRGF0ZTogU3VuLCAyNCBGZWIgMjAxMyAxNTozMzo0OCArMDEwMApTdWJq ZWN0OiBbUEFUQ0ggMjMvMjRdIFNpbXBsaWZ5IGFzc2VydGlvbiBjb25kaXRpb24sIHdoaWNo IGNvbnRhaW5zIGEKIGR1cGxpY2F0ZWQgc3ViZXhwcmVzc2lvbi4KCi0tLQogc3lzL2tlcm4v a2Vybl9kZXNjcmlwLmMgfCA1ICsrLS0tCiAxIGZpbGUgY2hhbmdlZCwgMiBpbnNlcnRpb25z KCspLCAzIGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL3N5cy9rZXJuL2tlcm5fZGVzY3Jp cC5jIGIvc3lzL2tlcm4va2Vybl9kZXNjcmlwLmMKaW5kZXggNjQxNzZjYS4uYzI1NTZlMiAx MDA2NDQKLS0tIGEvc3lzL2tlcm4va2Vybl9kZXNjcmlwLmMKKysrIGIvc3lzL2tlcm4va2Vy bl9kZXNjcmlwLmMKQEAgLTE0MjgsOSArMTQyOCw4IEBAIGZpbGVjYXBzX3ZhbGlkYXRlKGNv bnN0IHN0cnVjdCBmaWxlY2FwcyAqZmNhcHMsIGNvbnN0IGNoYXIgKmZ1bmMpCiAJICAgICgi JXM6IGludmFsaWQgZmNudGxzIiwgZnVuYykpOwogCUtBU1NFUlQoZmNhcHMtPmZjX2ZjbnRs cyA9PSAwIHx8IChmY2Fwcy0+ZmNfcmlnaHRzICYgQ0FQX0ZDTlRMKSAhPSAwLAogCSAgICAo IiVzOiBmY250bHMgd2l0aG91dCBDQVBfRkNOVEwiLCBmdW5jKSk7Ci0JS0FTU0VSVCgoKGZj YXBzLT5mY19uaW9jdGxzID09IC0xIHx8IGZjYXBzLT5mY19uaW9jdGxzID09IDApICYmCi0J ICAgICAgICAgZmNhcHMtPmZjX2lvY3RscyA9PSBOVUxMKSB8fAotCSAgICAgICAgKGZjYXBz LT5mY19uaW9jdGxzID4gMCAmJiBmY2Fwcy0+ZmNfaW9jdGxzICE9IE5VTEwpLAorCUtBU1NF UlQoZmNhcHMtPmZjX2lvY3RscyAhPSBOVUxMID8gZmNhcHMtPmZjX25pb2N0bHMgPiAwIDoK KwkgICAgKGZjYXBzLT5mY19uaW9jdGxzID09IC0xIHx8IGZjYXBzLT5mY19uaW9jdGxzID09 IDApLAogCSAgICAoIiVzOiBpbnZhbGlkIGlvY3RscyIsIGZ1bmMpKTsKIAlLQVNTRVJUKGZj YXBzLT5mY19uaW9jdGxzID09IDAgfHwgKGZjYXBzLT5mY19yaWdodHMgJiBDQVBfSU9DVEwp ICE9IDAsCiAJICAgICgiJXM6IGlvY3RscyB3aXRob3V0IENBUF9JT0NUTCIsIGZ1bmMpKTsK LS0gCjEuOC4xLjMKCg== --------------060105070608040709090402 Content-Type: text/plain; charset=UTF-8; name="0024-Factorise-code-to-free-a-file-descriptor.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="0024-Factorise-code-to-free-a-file-descriptor.patch" RnJvbSA5OGRkM2M4YTk4OGUwNDNiNGE4ZjAyZWQ0YzE5ZDM5ZDMwZTExNDVkIE1vbiBTZXAg MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBDaHJpc3RvcGggTWFsbG9uIDxjaHJpc3RvcGgubWFs bG9uQGdteC5kZT4KRGF0ZTogU3VuLCAyNCBGZWIgMjAxMyAxNTo0Nzo1MyArMDEwMApTdWJq ZWN0OiBbUEFUQ0ggMjQvMjRdIEZhY3RvcmlzZSBjb2RlIHRvIGZyZWUgYSBmaWxlIGRlc2Ny aXB0b3IuCgotLS0KIHN5cy9rZXJuL2tlcm5fZGVzY3JpcC5jIHwgMjkgKysrKysrKysrKysr KysrKystLS0tLS0tLS0tLS0KIDEgZmlsZSBjaGFuZ2VkLCAxNyBpbnNlcnRpb25zKCspLCAx MiBkZWxldGlvbnMoLSkKCmRpZmYgLS1naXQgYS9zeXMva2Vybi9rZXJuX2Rlc2NyaXAuYyBi L3N5cy9rZXJuL2tlcm5fZGVzY3JpcC5jCmluZGV4IGMyNTU2ZTIuLjgyNTY1MDEgMTAwNjQ0 Ci0tLSBhL3N5cy9rZXJuL2tlcm5fZGVzY3JpcC5jCisrKyBiL3N5cy9rZXJuL2tlcm5fZGVz Y3JpcC5jCkBAIC0yODcsNiArMjg3LDE5IEBAIGZkdW51c2VkKHN0cnVjdCBmaWxlZGVzYyAq ZmRwLCBpbnQgZmQpCiB9CiAKIC8qCisgKiBGcmVlIGEgZmlsZSBkZXNjcmlwdG9yLgorICov CitzdGF0aWMgdm9pZAorZmRmcmVlKHN0cnVjdCBmaWxlZGVzYyAqZmRwLCBpbnQgZmQpCit7 CisJc3RydWN0IGZpbGVkZXNjZW50ICpmZGUgPSBmZHAtPmZkX29maWxlc1tmZF07CisKKwlm aWxlY2Fwc19mcmVlKCZmZGUtPmZkZV9jYXBzKTsKKwliemVybyhmZGUsIHNpemVvZigqZmRl KSk7CisJZmR1bnVzZWQoZmRwLCBmZCk7Cit9CisKKy8qCiAgKiBTeXN0ZW0gY2FsbHMgb24g ZGVzY3JpcHRvcnMuCiAgKi8KICNpZm5kZWYgX1NZU19TWVNQUk9UT19IXwpAQCAtMTE2NSw5 ICsxMTc4LDcgQEAga2Vybl9jbG9zZSh0ZCwgZmQpCiAJCUZJTEVERVNDX1hVTkxPQ0soZmRw KTsKIAkJcmV0dXJuIChFQkFERik7CiAJfQotCWZpbGVjYXBzX2ZyZWUoJmZkcC0+ZmRfb2Zp bGVzW2ZkXS5mZGVfY2Fwcyk7Ci0JYnplcm8oJmZkcC0+ZmRfb2ZpbGVzW2ZkXSwgc2l6ZW9m KGZkcC0+ZmRfb2ZpbGVzW2ZkXSkpOwotCWZkdW51c2VkKGZkcCwgZmQpOworCWZkZnJlZShm ZHAsIGZkKTsKIAogCS8qIGNsb3NlZnAoKSBkcm9wcyB0aGUgRklMRURFU0MgbG9jayBmb3Ig dXMuICovCiAJcmV0dXJuIChjbG9zZWZwKGZkcCwgZmQsIGZwLCB0ZCwgMSkpOwpAQCAtMjAz NSw5ICsyMDQ2LDcgQEAgc2V0dWdpZHNhZmV0eShzdHJ1Y3QgdGhyZWFkICp0ZCkKIAkJCSAq IE5VTEwtb3V0IGRlc2NyaXB0b3IgcHJpb3IgdG8gY2xvc2UgdG8gYXZvaWQKIAkJCSAqIGEg cmFjZSB3aGlsZSBjbG9zZSBibG9ja3MuCiAJCQkgKi8KLQkJCWZpbGVjYXBzX2ZyZWUoJmZk cC0+ZmRfb2ZpbGVzW2ldLmZkZV9jYXBzKTsKLQkJCWJ6ZXJvKCZmZHAtPmZkX29maWxlc1tp XSwgc2l6ZW9mKGZkcC0+ZmRfb2ZpbGVzW2ldKSk7Ci0JCQlmZHVudXNlZChmZHAsIGkpOwor CQkJZmRmcmVlKGZkcCwgaSk7CiAJCQlGSUxFREVTQ19YVU5MT0NLKGZkcCk7CiAJCQkodm9p ZCkgY2xvc2VmKGZwLCB0ZCk7CiAJCQlGSUxFREVTQ19YTE9DSyhmZHApOwpAQCAtMjA1OSw5 ICsyMDY4LDcgQEAgZmRjbG9zZShzdHJ1Y3QgZmlsZWRlc2MgKmZkcCwgc3RydWN0IGZpbGUg KmZwLCBpbnQgaWR4LCBzdHJ1Y3QgdGhyZWFkICp0ZCkKIAogCUZJTEVERVNDX1hMT0NLKGZk cCk7CiAJaWYgKGZkcC0+ZmRfb2ZpbGVzW2lkeF0uZmRlX2ZpbGUgPT0gZnApIHsKLQkJZmls ZWNhcHNfZnJlZSgmZmRwLT5mZF9vZmlsZXNbaWR4XS5mZGVfY2Fwcyk7Ci0JCWJ6ZXJvKCZm ZHAtPmZkX29maWxlc1tpZHhdLCBzaXplb2YoZmRwLT5mZF9vZmlsZXNbaWR4XSkpOwotCQlm ZHVudXNlZChmZHAsIGlkeCk7CisJCWZkZnJlZShmZHAsIGlkeCk7CiAJCUZJTEVERVNDX1hV TkxPQ0soZmRwKTsKIAkJZmRyb3AoZnAsIHRkKTsKIAl9IGVsc2UKQEAgLTIwOTQsOSArMjEw MSw3IEBAIGZkY2xvc2VleGVjKHN0cnVjdCB0aHJlYWQgKnRkKQogCQlmcCA9IGZkZS0+ZmRl X2ZpbGU7CiAJCWlmIChmcCAhPSBOVUxMICYmIChmcC0+Zl90eXBlID09IERUWVBFX01RVUVV RSB8fAogCQkgICAgKGZkZS0+ZmRlX2ZsYWdzICYgVUZfRVhDTE9TRSkpKSB7Ci0JCQlmaWxl Y2Fwc19mcmVlKCZmZGUtPmZkZV9jYXBzKTsKLQkJCWJ6ZXJvKGZkZSwgc2l6ZW9mKCpmZGUp KTsKLQkJCWZkdW51c2VkKGZkcCwgaSk7CisJCQlmZGZyZWUoZmRwLCBpKTsKIAkJCSh2b2lk KSBjbG9zZWZwKGZkcCwgaSwgZnAsIHRkLCAwKTsKIAkJCS8qIGNsb3NlZnAoKSBkcm9wcyB0 aGUgRklMRURFU0MgbG9jay4gKi8KIAkJCUZJTEVERVNDX1hMT0NLKGZkcCk7Ci0tIAoxLjgu MS4zCgo= --------------060105070608040709090402-- From owner-freebsd-arch@FreeBSD.ORG Sun Feb 24 19:29:59 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 A42116A for ; Sun, 24 Feb 2013 19:29:59 +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 6317FF82 for ; Sun, 24 Feb 2013 19:29: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 1204EAF7; Sun, 24 Feb 2013 20:26:54 +0100 (CET) Date: Sun, 24 Feb 2013 20:30:58 +0100 From: Pawel Jakub Dawidek To: Christoph Mallon Subject: Re: Large Capsicum patch for review. Message-ID: <20130224193058.GW1377@garage.freebsd.pl> References: <20130213025547.GA2025@garage.freebsd.pl> <20130213230221.GB1375@garage.freebsd.pl> <20130223221116.GR1377@garage.freebsd.pl> <5129ADC5.5040306@gmx.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vRjLMflJ/YJvC+Q3" Content-Disposition: inline In-Reply-To: <5129ADC5.5040306@gmx.de> 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, 24 Feb 2013 19:29:59 -0000 --vRjLMflJ/YJvC+Q3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Feb 24, 2013 at 07:05:57AM +0100, Christoph Mallon wrote: > Hi. >=20 > On 23.02.2013 23:11, Pawel Jakub Dawidek wrote: > > On Thu, Feb 14, 2013 at 12:02:22AM +0100, Pawel Jakub Dawidek wrote: > >> I'd like to commit this patch: > >> > >> http://people.freebsd.org/~pjd/patches/capkern.diff > >=20 > > The patch was updated after the following changes and is available at > > the link above: >=20 > I was not able to apply this patch cleanly and had to fudge with the diff: > - Two diff headers (contrib/openbsm/etc/audit_event and lib/libc/gen/Make= file.inc) have an extra space after --- and +++, which is recognized as par= t of the filename. > Was this patch manually altered? Nope, but I'm using some script to generate patch(1)-compatbile diff =66rom a perforce diff. > - Two diffs (lib/libc/sys/cap_new.2 and sys/kern/uipc_mqueue.c) contain u= nexpanded $FreeBSD$ tags. > I also had to guess, that the patch is to be applied onto r247201. > I placed a cleaned up patch at http://tron.homeunix.org/zeug/FreeBSD/caps= icum/0001-Capsicum-update.patch. >=20 > This is a really big patch bomb changing lots of unrelated things. > Do you have smaller, more managable diffs for easier review? I don't have smaller patch, unfortunately, but I don't think there are unrelated things in there. Can you point me at them? > I started reading the patch and found some minor glitches, e.g. mode in c= ap_sandboxed() should be u_int, not int. > I will report more later. I updated the patch. It is now against r247212. Thanks! --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --vRjLMflJ/YJvC+Q3 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlEqanIACgkQForvXbEpPzQCogCg+Rqb9z9u79/kKuYpRFhXYmpO bMMAoO5QsaHey4doF5qHEL9lHe2ax2Xx =gs/B -----END PGP SIGNATURE----- --vRjLMflJ/YJvC+Q3-- From owner-freebsd-arch@FreeBSD.ORG Sun Feb 24 23:58: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 34373FA1 for ; Sun, 24 Feb 2013 23:58: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 3FBC6EDC for ; Sun, 24 Feb 2013 23:58:31 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id 3F2C9BA4; Mon, 25 Feb 2013 00:55:32 +0100 (CET) Date: Mon, 25 Feb 2013 00:59:36 +0100 From: Pawel Jakub Dawidek To: Christoph Mallon Subject: Re: Large Capsicum patch for review. Message-ID: <20130224235936.GX1377@garage.freebsd.pl> References: <20130213025547.GA2025@garage.freebsd.pl> <20130213230221.GB1375@garage.freebsd.pl> <20130223221116.GR1377@garage.freebsd.pl> <5129ADC5.5040306@gmx.de> <512A2CA0.2050509@gmx.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yTwVabqJa5IUz21H" Content-Disposition: inline In-Reply-To: <512A2CA0.2050509@gmx.de> 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, 24 Feb 2013 23:58:33 -0000 --yTwVabqJa5IUz21H Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Feb 24, 2013 at 04:07:12PM +0100, Christoph Mallon wrote: > On 24.02.2013 07:05, Christoph Mallon wrote: > > I started reading the patch and found some minor glitches, e.g. mode in= cap_sandboxed() should be u_int, not int. > > I will report more later. >=20 > I placed several patches with suggested changes at http://tron.homeunix.o= rg/zeug/FreeBSD/capsicum/ (I also attached them). > Please have a look at them. > I also have some comments: > - A bitmask for cap_rights_limit() seems limited. > There are only six bits left unused. > Maybe a more general mechanism should be used. Yes, we are aware of this. bindat(2) and connectat(2) takes two more. Solution is not decided yet. > - I think that CAP_SEND, CAP_RECV, CAP_FCHMODAT, CAP_FCHOWNAT, CAP_FSTATA= T and CAP_FUTIMESAT are pointless aliases, which provide no benefit, but ra= ther might cause confusion, whether there is a difference between e.g. CAP_= WRITE and CAP_SEND. I am little worry that it might cause confusion, but not providing them would make it even more confusing, as it wouldn't be obvious which right should I have for send(2) to work. The aliases match system calls nicely. They are also documented as aliases in cap_rights_limit(2). > - Why did you choose INT_MAX to represent "all capabilities"? > The data type used is ssize_t, so SSIZE_MAX seems more logical. > Further, there are several places where size_t and ssize_t come into co= ntact, which need careful tests and casts to get right. > Maybe it is better to always use size_t and represent "all capabilities= " with SIZE_T_MAX or (size_t)-1 (which is guaranteed by C to be the maximal= value). This is not used for capabilities, but for white-listing ioctl commands. INT_MAX seems to just be least odd. We only allow for 256 anyway. I could provide some dedicated define for it, eg. #define CAP_IOCTLS_ALL > - Is it correct, that fdp seems to be not locked in fp_getfvp()? > Otherweise, fget_locked() could be used instead of the manual check. Yeah, I don't like this too, but AFAIR it doesn't have to be locked, as it is used by nfsd processes only that don't manipulate filedesc table. This is at least what I recall I was told. > - I could not verify many changes, e.g. changed requested permissions, be= cause this is just a big diff with no information about the intention of th= e changes. > A series of smaller diffs with commit logs to state their intent would = be really useful for reviewing. The entire history is in perforce, but there are many commits in there. The key goals of the patch are: - Move from special capability descriptors that were used to keep capability rights in the file structure to ability to configure capability rights on any descriptor type. - Make capability rights more practical. - Allow for ioctl(2) in capability mode by providing a way to limit permitted ioctl commands. - Allow for limiting permitted fcntl(2) commands. You can find comments to your patches below. Thank you very much for the changes. I updated the patch: http://people.freebsd.org/~pjd/patches/capkern.diff > From 7f18186c451c235bcc3dbf2e25f65613e1ce7f16 Mon Sep 17 00:00:00 2001 > From: Christoph Mallon > Date: Sun, 24 Feb 2013 13:01:00 +0100 > Subject: [PATCH 02/24] Use the correct type for the parameter of > cap_getmode(). >=20 > --- > lib/libc/gen/cap_sandboxed.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) >=20 > diff --git a/lib/libc/gen/cap_sandboxed.c b/lib/libc/gen/cap_sandboxed.c > index 95e5b23..5743f2a 100644 > --- a/lib/libc/gen/cap_sandboxed.c > +++ b/lib/libc/gen/cap_sandboxed.c > @@ -39,7 +39,7 @@ __FBSDID("$FreeBSD$"); > bool > cap_sandboxed(void) > { > - int mode; > + u_int mode; > =20 > if (cap_getmode(&mode) =3D=3D -1) { > assert(errno =3D=3D ENOSYS); Applied, although I prefer 'unsigned int' in userland. > From 7ad09a0cf0ceb9828171133e32f7148ffde62d97 Mon Sep 17 00:00:00 2001 > From: Christoph Mallon > Date: Sun, 24 Feb 2013 13:03:03 +0100 > Subject: [PATCH 03/24] Use cheaper !=3D 0 tests. >=20 > --- > lib/libc/gen/cap_sandboxed.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) >=20 > diff --git a/lib/libc/gen/cap_sandboxed.c b/lib/libc/gen/cap_sandboxed.c > index 5743f2a..f09b590 100644 > --- a/lib/libc/gen/cap_sandboxed.c > +++ b/lib/libc/gen/cap_sandboxed.c > @@ -41,10 +41,10 @@ cap_sandboxed(void) > { > u_int mode; > =20 > - if (cap_getmode(&mode) =3D=3D -1) { > + if (cap_getmode(&mode) !=3D 0) { > assert(errno =3D=3D ENOSYS); > return (false); > } > assert(mode =3D=3D 0 || mode =3D=3D 1); > - return (mode =3D=3D 1); > + return (mode !=3D 0); > } I prefer comparison with -1, so I skipped this one. > From ae6ac8b82374e83dcc2bda7dd6e17da5d65d9eae Mon Sep 17 00:00:00 2001 > From: Christoph Mallon > Date: Sun, 24 Feb 2013 13:03:24 +0100 > Subject: [PATCH 04/24] Add cap_sandboxed to Symbol.map. >=20 > --- > lib/libc/sys/Symbol.map | 1 + > 1 file changed, 1 insertion(+) >=20 > diff --git a/lib/libc/sys/Symbol.map b/lib/libc/sys/Symbol.map > index 376ace0..7738e46 100644 > --- a/lib/libc/sys/Symbol.map > +++ b/lib/libc/sys/Symbol.map > @@ -384,6 +384,7 @@ FBSD_1.3 { > cap_ioctls_limit; > cap_rights_get; > cap_rights_limit; > + cap_sandboxed; > clock_getcpuclockid2; > ffclock_getcounter; > ffclock_getestimate; Applied. > From 4822faec8ea5c53c673740eeec0cb604960af37b Mon Sep 17 00:00:00 2001 > From: Christoph Mallon > Date: Sun, 24 Feb 2013 13:03:59 +0100 > Subject: [PATCH 05/24] Use standard inline instead of the GNUism __inline. >=20 > --- > sys/kern/sys_capability.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) >=20 > diff --git a/sys/kern/sys_capability.c b/sys/kern/sys_capability.c > index 941ea49..0f4ef12 100644 > --- a/sys/kern/sys_capability.c > +++ b/sys/kern/sys_capability.c > @@ -144,7 +144,7 @@ sys_cap_getmode(struct thread *td, struct cap_getmode= _args *uap) > =20 > FEATURE(security_capabilities, "Capsicum Capabilities"); > =20 > -static __inline int > +static inline int > _cap_check(cap_rights_t have, cap_rights_t need, enum ktr_cap_fail_type = type) > { > =20 Applied. > From 1d1defdf7dd117afa56330c958daeac5d52be05f Mon Sep 17 00:00:00 2001 > From: Christoph Mallon > Date: Sun, 24 Feb 2013 13:04:41 +0100 > Subject: [PATCH 06/24] Avoid polluting the global namespace with stdbool.= h. >=20 > --- > sys/sys/capability.h | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) >=20 > diff --git a/sys/sys/capability.h b/sys/sys/capability.h > index df95ae4..9eed4d1 100644 > --- a/sys/sys/capability.h > +++ b/sys/sys/capability.h > @@ -251,7 +251,6 @@ int cap_fcntl_check(struct filedesc *fdp, int fd, int= cmd); > #else /* !_KERNEL */ > =20 > __BEGIN_DECLS > -#include > =20 > /* > * cap_enter(): Cause the process to enter capability mode, which will > @@ -270,7 +269,7 @@ int cap_enter(void); > * Are we sandboxed (in capability mode)? > * This is libc wrapper around cap_getmode(2) system call. > */ > -bool cap_sandboxed(void); > +_Bool cap_sandboxed(void); > =20 > /* > * cap_getmode(): Are we in capability mode? Not sure yet about this one. > From 5107ab9aec6766c9ce5285939637c5739b2aed0c Mon Sep 17 00:00:00 2001 > From: Christoph Mallon > Date: Sun, 24 Feb 2013 13:05:19 +0100 > Subject: [PATCH 07/24] Use ${CC} instead of hardcoding gcc. >=20 > --- > tools/regression/capsicum/syscalls/Makefile | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) >=20 > diff --git a/tools/regression/capsicum/syscalls/Makefile b/tools/regressi= on/capsicum/syscalls/Makefile > index cb1b07b..5d34226 100644 > --- a/tools/regression/capsicum/syscalls/Makefile > +++ b/tools/regression/capsicum/syscalls/Makefile > @@ -14,7 +14,7 @@ all: ${SYSCALLS} ${SYSCALLS:=3D.t} > .for SYSCALL in ${SYSCALLS} > =20 > ${SYSCALL}: ${SYSCALL}.c misc.c > - gcc ${CFLAGS} ${@}.c misc.c -o $@ > + ${CC} ${CFLAGS} ${@}.c misc.c -o $@ > =20 > ${SYSCALL}.t: ${SYSCALL} > @printf "#!/bin/sh\n\n%s/%s\n" ${.CURDIR} ${@:.t=3D} > $@ Applied. > From d2fe7a6f9d8e08943600b1f5d6a2818c6c4aa794 Mon Sep 17 00:00:00 2001 > From: Christoph Mallon > Date: Sun, 24 Feb 2013 13:31:37 +0100 > Subject: [PATCH 08/24] Use fget_locked() instead of duplicating it. >=20 > --- > sys/kern/uipc_usrreq.c | 3 +-- > sys/netsmb/smb_dev.c | 4 +--- > 2 files changed, 2 insertions(+), 5 deletions(-) >=20 > diff --git a/sys/kern/uipc_usrreq.c b/sys/kern/uipc_usrreq.c > index 15a1c8a..529d2eb 100644 > --- a/sys/kern/uipc_usrreq.c > +++ b/sys/kern/uipc_usrreq.c > @@ -1858,8 +1858,7 @@ unp_internalize(struct mbuf **controlp, struct thre= ad *td) > FILEDESC_SLOCK(fdesc); > for (i =3D 0; i < oldfds; i++) { > fd =3D *fdp++; > - if (fd < 0 || fd >=3D fdesc->fd_nfiles || > - fdesc->fd_ofiles[fd].fde_file =3D=3D NULL) { > + if (fget_locked(fdp, fd) =3D=3D NULL) { > FILEDESC_SUNLOCK(fdesc); > error =3D EBADF; > goto out; > diff --git a/sys/netsmb/smb_dev.c b/sys/netsmb/smb_dev.c > index 0cee325..a09d74d 100644 > --- a/sys/netsmb/smb_dev.c > +++ b/sys/netsmb/smb_dev.c > @@ -399,9 +399,7 @@ nsmb_getfp(struct filedesc* fdp, int fd, int flag) > struct file* fp; > =20 > FILEDESC_SLOCK(fdp); > - if (fd < 0 || fd >=3D fdp->fd_nfiles || > - (fp =3D fdp->fd_ofiles[fd].fde_file) =3D=3D NULL || > - (fp->f_flag & flag) =3D=3D 0) { > + if ((fp =3D fget_locked(fdp, fd)) =3D=3D NULL || (fp->f_flag & flag) = =3D=3D 0) { > FILEDESC_SUNLOCK(fdp); > return (NULL); > } Applied. > From cc2de42e944828943c17fcba2a821becc634b9a4 Mon Sep 17 00:00:00 2001 > From: Christoph Mallon > Date: Sun, 24 Feb 2013 13:33:49 +0100 > Subject: [PATCH 09/24] Remove duplicate checks. >=20 > fget_locked() just below does the same checks. > --- > sys/kern/kern_descrip.c | 5 ----- > 1 file changed, 5 deletions(-) >=20 > diff --git a/sys/kern/kern_descrip.c b/sys/kern/kern_descrip.c > index bed5d8f..473ab40 100644 > --- a/sys/kern/kern_descrip.c > +++ b/sys/kern/kern_descrip.c > @@ -2459,11 +2459,6 @@ fgetvp_rights(struct thread *td, int fd, cap_right= s_t need, > if (td =3D=3D NULL || (fdp =3D td->td_proc->p_fd) =3D=3D NULL) > return (EBADF); > =20 > - FILEDESC_LOCK_ASSERT(fdp); > - > - if (fd < 0 || fd >=3D fdp->fd_nfiles) > - return (EBADF); > - > fp =3D fget_locked(fdp, fd); > if (fp =3D=3D NULL || fp->f_ops =3D=3D &badfileops) > return (EBADF); Applied. > From 2b9add7396a9485add6a4246071cf041a50161d1 Mon Sep 17 00:00:00 2001 > From: Christoph Mallon > Date: Sun, 24 Feb 2013 13:34:43 +0100 > Subject: [PATCH 10/24] Make fp_getfvp() static. >=20 > --- > sys/fs/nfs/nfsdport.h | 2 -- > sys/fs/nfsserver/nfs_nfsdport.c | 2 +- > 2 files changed, 1 insertion(+), 3 deletions(-) >=20 > diff --git a/sys/fs/nfs/nfsdport.h b/sys/fs/nfs/nfsdport.h > index 529ada2..a09a6dd 100644 > --- a/sys/fs/nfs/nfsdport.h > +++ b/sys/fs/nfs/nfsdport.h > @@ -94,8 +94,6 @@ struct nfsexstuff { > #define NFSFPCRED(f) ((f)->f_cred) > #define NFSFPFLAG(f) ((f)->f_flag) > =20 > -int fp_getfvp(NFSPROC_T *, int, struct file **, struct vnode **); > - > #define NFSNAMEICNDSET(n, c, o, f) do { \ > (n)->cn_cred =3D (c); \ > (n)->cn_nameiop =3D (o); \ > diff --git a/sys/fs/nfsserver/nfs_nfsdport.c b/sys/fs/nfsserver/nfs_nfsdp= ort.c > index cd7814c..880f965 100644 > --- a/sys/fs/nfsserver/nfs_nfsdport.c > +++ b/sys/fs/nfsserver/nfs_nfsdport.c > @@ -2767,7 +2767,7 @@ out: > /* > * glue for fp. > */ > -int > +static int > fp_getfvp(struct thread *p, int fd, struct file **fpp, struct vnode **vp= p) > { > struct filedesc *fdp; Applied. > From 4645cc6db54f29c1f5ec32c47794fd135f99cf60 Mon Sep 17 00:00:00 2001 > From: Christoph Mallon > Date: Sun, 24 Feb 2013 13:37:22 +0100 > Subject: [PATCH 11/24] Use simple assignment instead of bcopy() to copy > structs. >=20 > --- > sys/kern/kern_descrip.c | 15 ++++++--------- > 1 file changed, 6 insertions(+), 9 deletions(-) >=20 > diff --git a/sys/kern/kern_descrip.c b/sys/kern/kern_descrip.c > index 473ab40..94bb74a 100644 > --- a/sys/kern/kern_descrip.c > +++ b/sys/kern/kern_descrip.c > @@ -839,8 +839,7 @@ do_dup(struct thread *td, int flags, int old, int new, > /* > * Duplicate the source descriptor. > */ > - bcopy(&fdp->fd_ofiles[old], &fdp->fd_ofiles[new], > - sizeof(fdp->fd_ofiles[new])); > + fdp->fd_ofiles[new] =3D fdp->fd_ofiles[old]; > filecaps_copy(&fdp->fd_ofiles[old].fde_caps, > &fdp->fd_ofiles[new].fde_caps); > if ((flags & DUP_CLOEXEC) !=3D 0) { > @@ -1374,7 +1373,7 @@ filecaps_copy(const struct filecaps *src, struct fi= lecaps *dst) > { > size_t size; > =20 > - bcopy(src, dst, sizeof(*dst)); > + *dst =3D *src; > if (src->fc_ioctls !=3D NULL) { > KASSERT(src->fc_nioctls > 0, > ("fc_ioctls !=3D NULL, but fc_nioctls=3D%hd", src->fc_nioctls)); > @@ -1392,7 +1391,7 @@ static void > filecaps_move(struct filecaps *src, struct filecaps *dst) > { > =20 > - bcopy(src, dst, sizeof(*dst)); > + *dst =3D *src; > bzero(src, sizeof(*src)); > } > =20 > @@ -1835,7 +1834,7 @@ fdcopy(struct filedesc *fdp) > (ofde->fde_file->f_ops->fo_flags & DFLAG_PASSABLE) && > ofde->fde_file->f_ops !=3D &badfileops) { > nfde =3D &newfdp->fd_ofiles[i]; > - bcopy(ofde, nfde, sizeof(*nfde)); > + *nfde =3D *ofde; > filecaps_copy(&ofde->fde_caps, &nfde->fde_caps); > fhold(nfde->fde_file); > newfdp->fd_lastfile =3D i; > @@ -2681,8 +2680,7 @@ dupfdopen(struct thread *td, struct filedesc *fdp, = int dfd, int mode, > return (EACCES); > } > fhold(fp); > - bcopy(&fdp->fd_ofiles[dfd], &fdp->fd_ofiles[indx], > - sizeof(fdp->fd_ofiles[indx])); > + fdp->fd_ofiles[indx] =3D fdp->fd_ofiles[dfd]; > filecaps_copy(&fdp->fd_ofiles[dfd].fde_caps, > &fdp->fd_ofiles[indx].fde_caps); > break; > @@ -2690,8 +2688,7 @@ dupfdopen(struct thread *td, struct filedesc *fdp, = int dfd, int mode, > /* > * Steal away the file pointer from dfd and stuff it into indx. > */ > - bcopy(&fdp->fd_ofiles[dfd], &fdp->fd_ofiles[indx], > - sizeof(fdp->fd_ofiles[indx])); > + fdp->fd_ofiles[indx] =3D fdp->fd_ofiles[dfd]; > bzero(&fdp->fd_ofiles[dfd], sizeof(fdp->fd_ofiles[dfd])); > fdunused(fdp, dfd); > break; Applied. > From fc8878d0a43ea3f9d77b1fd51f90f4b4be188fb2 Mon Sep 17 00:00:00 2001 > From: Christoph Mallon > Date: Sun, 24 Feb 2013 13:40:32 +0100 > Subject: [PATCH 12/24] Remove redundant null pointer tests before free(). >=20 > --- > sys/kern/kern_descrip.c | 3 +-- > sys/kern/sys_capability.c | 15 +++++---------- > 2 files changed, 6 insertions(+), 12 deletions(-) >=20 > diff --git a/sys/kern/kern_descrip.c b/sys/kern/kern_descrip.c > index 94bb74a..53b24b1 100644 > --- a/sys/kern/kern_descrip.c > +++ b/sys/kern/kern_descrip.c > @@ -1415,8 +1415,7 @@ void > filecaps_free(struct filecaps *fcaps) > { > =20 > - if (fcaps->fc_ioctls !=3D NULL) > - free(fcaps->fc_ioctls, M_TEMP); > + free(fcaps->fc_ioctls, M_TEMP); > bzero(fcaps, sizeof(*fcaps)); > } > =20 > diff --git a/sys/kern/sys_capability.c b/sys/kern/sys_capability.c > index 0f4ef12..ecb3a6b 100644 > --- a/sys/kern/sys_capability.c > +++ b/sys/kern/sys_capability.c > @@ -228,10 +228,8 @@ sys_cap_rights_limit(struct thread *td, struct cap_r= ights_limit_args *uap) > if (error =3D=3D 0) { > fdp->fd_ofiles[fd].fde_rights =3D rights; > if ((rights & CAP_IOCTL) =3D=3D 0) { > - if (fdp->fd_ofiles[fd].fde_ioctls !=3D NULL) { > - free(fdp->fd_ofiles[fd].fde_ioctls, M_TEMP); > - fdp->fd_ofiles[fd].fde_ioctls =3D NULL; > - } > + free(fdp->fd_ofiles[fd].fde_ioctls, M_TEMP); > + fdp->fd_ofiles[fd].fde_ioctls =3D NULL; > fdp->fd_ofiles[fd].fde_nioctls =3D 0; > } > if ((rights & CAP_FCNTL) =3D=3D 0 && > @@ -376,8 +374,7 @@ sys_cap_ioctls_limit(struct thread *td, struct cap_io= ctls_limit_args *uap) > =20 > FILEDESC_XUNLOCK(fdp); > =20 > - if (ocmds !=3D NULL) > - free(ocmds, M_TEMP); > + free(ocmds, M_TEMP); > =20 > return (0); > } > @@ -556,10 +553,8 @@ sys_cap_new(struct thread *td, struct cap_new_args *= uap) > */ > fdp->fd_ofiles[newfd].fde_rights =3D rights; > if ((rights & CAP_IOCTL) =3D=3D 0) { > - if (fdp->fd_ofiles[newfd].fde_ioctls !=3D NULL) { > - free(fdp->fd_ofiles[newfd].fde_ioctls, M_TEMP); > - fdp->fd_ofiles[newfd].fde_ioctls =3D NULL; > - } > + free(fdp->fd_ofiles[newfd].fde_ioctls, M_TEMP); > + fdp->fd_ofiles[newfd].fde_ioctls =3D NULL; > fdp->fd_ofiles[newfd].fde_nioctls =3D 0; > } > if ((rights & CAP_FCNTL) =3D=3D 0 && fdp->fd_ofiles[newfd].fde_fcntls != =3D 0) Applied. > From 41fc1f39a18331f57e6a03b54f4b78cbbd123cd5 Mon Sep 17 00:00:00 2001 > From: Christoph Mallon > Date: Sun, 24 Feb 2013 13:41:38 +0100 > Subject: [PATCH 13/24] Remove redundant test. >=20 > if needrights is 0, the inner tests will succeed. > --- > sys/kern/kern_descrip.c | 12 +++++------- > 1 file changed, 5 insertions(+), 7 deletions(-) >=20 > diff --git a/sys/kern/kern_descrip.c b/sys/kern/kern_descrip.c > index 53b24b1..d1465a0 100644 > --- a/sys/kern/kern_descrip.c > +++ b/sys/kern/kern_descrip.c > @@ -2270,15 +2270,13 @@ fget_unlocked(struct filedesc *fdp, int fd, cap_r= ights_t needrights, > return (EBADF); > #ifdef CAPABILITIES > haverights =3D cap_rights(fdp, fd); > - if (needrights !=3D 0) { > - error =3D cap_check(haverights, needrights); > + error =3D cap_check(haverights, needrights); > + if (error !=3D 0) > + return (error); > + if ((needrights & CAP_FCNTL) !=3D 0) { > + error =3D cap_fcntl_check(fdp, fd, needfcntl); > if (error !=3D 0) > return (error); > - if ((needrights & CAP_FCNTL) !=3D 0) { > - error =3D cap_fcntl_check(fdp, fd, needfcntl); > - if (error !=3D 0) > - return (error); > - } > } > #endif > count =3D fp->f_count; Applied. > From d4c8e6bbeb678867b2bd1c0ec09faf60642465d0 Mon Sep 17 00:00:00 2001 > From: Christoph Mallon > Date: Sun, 24 Feb 2013 13:43:28 +0100 > Subject: [PATCH 14/24] Avoide double test. >=20 > --- > sys/kern/sys_capability.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) >=20 > diff --git a/sys/kern/sys_capability.c b/sys/kern/sys_capability.c > index ecb3a6b..dbbda01 100644 > --- a/sys/kern/sys_capability.c > +++ b/sys/kern/sys_capability.c > @@ -314,12 +314,12 @@ cap_ioctl_limit_check(struct filedesc *fdp, int fd,= const u_long *cmds, > =20 > ocmds =3D fdp->fd_ofiles[fd].fde_ioctls; > for (i =3D 0; i < ncmds; i++) { > - for (j =3D 0; j < oncmds; j++) { > + for (j =3D 0;; j++) { > + if (j =3D=3D oncmds) > + return (ENOTCAPABLE); > if (cmds[i] =3D=3D ocmds[j]) > break; > } > - if (j =3D=3D oncmds) > - return (ENOTCAPABLE); > } > =20 > return (0); I decided to skip this one. My version is more readable, IMHO, as it is used for other cases like TAILQ_FOREACH(), etc. where the check is already done by the macro. > From ba10274ab48bf9b2a2e6b8d50c59eb24074e6ec0 Mon Sep 17 00:00:00 2001 > From: Christoph Mallon > Date: Sun, 24 Feb 2013 13:45:09 +0100 > Subject: [PATCH 15/24] Simplify if (x !=3D 0) x =3D 0; to just x =3D 0;. >=20 > --- > sys/kern/sys_capability.c | 6 ++---- > 1 file changed, 2 insertions(+), 4 deletions(-) >=20 > diff --git a/sys/kern/sys_capability.c b/sys/kern/sys_capability.c > index dbbda01..153364b 100644 > --- a/sys/kern/sys_capability.c > +++ b/sys/kern/sys_capability.c > @@ -232,10 +232,8 @@ sys_cap_rights_limit(struct thread *td, struct cap_r= ights_limit_args *uap) > fdp->fd_ofiles[fd].fde_ioctls =3D NULL; > fdp->fd_ofiles[fd].fde_nioctls =3D 0; > } > - if ((rights & CAP_FCNTL) =3D=3D 0 && > - fdp->fd_ofiles[fd].fde_fcntls !=3D 0) { > + if ((rights & CAP_FCNTL) =3D=3D 0) > fdp->fd_ofiles[fd].fde_fcntls =3D 0; > - } > } > FILEDESC_XUNLOCK(fdp); > return (error); > @@ -557,7 +555,7 @@ sys_cap_new(struct thread *td, struct cap_new_args *u= ap) > fdp->fd_ofiles[newfd].fde_ioctls =3D NULL; > fdp->fd_ofiles[newfd].fde_nioctls =3D 0; > } > - if ((rights & CAP_FCNTL) =3D=3D 0 && fdp->fd_ofiles[newfd].fde_fcntls != =3D 0) > + if ((rights & CAP_FCNTL) =3D=3D 0) > fdp->fd_ofiles[newfd].fde_fcntls =3D 0; > FILEDESC_XUNLOCK(fdp); > =20 Applied. > From 38ec55338714e68b845ee45272fac7e7333727ef Mon Sep 17 00:00:00 2001 > From: Christoph Mallon > Date: Sun, 24 Feb 2013 13:47:23 +0100 > Subject: [PATCH 16/24] Reduce indentation. >=20 > --- > sys/kern/kern_descrip.c | 14 ++++++-------- > 1 file changed, 6 insertions(+), 8 deletions(-) >=20 > diff --git a/sys/kern/kern_descrip.c b/sys/kern/kern_descrip.c > index d1465a0..612d51a 100644 > --- a/sys/kern/kern_descrip.c > +++ b/sys/kern/kern_descrip.c > @@ -2463,15 +2463,13 @@ fgetvp_rights(struct thread *td, int fd, cap_righ= ts_t need, > if (error !=3D 0) > return (error); > =20 > - if (fp->f_vnode =3D=3D NULL) { > - error =3D EINVAL; > - } else { > - *vpp =3D fp->f_vnode; > - vref(*vpp); > - filecaps_copy(&fdp->fd_ofiles[fd].fde_caps, havecaps); > - } > + if (fp->f_vnode =3D=3D NULL) > + return EINVAL; > =20 > - return (error); > + *vpp =3D fp->f_vnode; > + vref(*vpp); > + filecaps_copy(&fdp->fd_ofiles[fd].fde_caps, havecaps); > + return (0); > } > =20 > int Applied. > From 64e66277c265b3a1221d9e269c8f33345e43332c Mon Sep 17 00:00:00 2001 > From: Christoph Mallon > Date: Sun, 24 Feb 2013 13:49:37 +0100 > Subject: [PATCH 17/24] Avoid code duplication on error paths. >=20 > --- > sys/kern/sys_capability.c | 42 ++++++++++++++++++------------------------ > 1 file changed, 18 insertions(+), 24 deletions(-) >=20 > diff --git a/sys/kern/sys_capability.c b/sys/kern/sys_capability.c > index 153364b..e87a4e5 100644 > --- a/sys/kern/sys_capability.c > +++ b/sys/kern/sys_capability.c > @@ -344,37 +344,32 @@ sys_cap_ioctls_limit(struct thread *td, struct cap_= ioctls_limit_args *uap) > } else { > cmds =3D malloc(sizeof(cmds[0]) * ncmds, M_TEMP, M_WAITOK); > error =3D copyin(uap->cmds, cmds, sizeof(cmds[0]) * ncmds); > - if (error !=3D 0) { > - free(cmds, M_TEMP); > - return (error); > - } > + if (error !=3D 0) > + goto out; > } > =20 > fdp =3D td->td_proc->p_fd; > FILEDESC_XLOCK(fdp); > =20 > if (fget_locked(fdp, fd) =3D=3D NULL) { > - FILEDESC_XUNLOCK(fdp); > - free(cmds, M_TEMP); > - return (EBADF); > + error =3D EBADF; > + goto out_locked; > } > =20 > error =3D cap_ioctl_limit_check(fdp, fd, cmds, ncmds); > - if (error !=3D 0) { > - FILEDESC_XUNLOCK(fdp); > - free(cmds, M_TEMP); > - return (error); > - } > + if (error !=3D 0) > + goto out_locked; > =20 > ocmds =3D fdp->fd_ofiles[fd].fde_ioctls; > fdp->fd_ofiles[fd].fde_ioctls =3D cmds; > fdp->fd_ofiles[fd].fde_nioctls =3D ncmds; > + cmds =3D ocmds; > =20 > +out_locked: > FILEDESC_XUNLOCK(fdp); > - > - free(ocmds, M_TEMP); > - > - return (0); > +out: > + free(cmds, M_TEMP); > + return (error); > } > =20 > int > @@ -396,8 +391,8 @@ sys_cap_ioctls_get(struct thread *td, struct cap_ioct= ls_get_args *uap) > FILEDESC_SLOCK(fdp); > =20 > if (fget_locked(fdp, fd) =3D=3D NULL) { > - FILEDESC_SUNLOCK(fdp); > - return (EBADF); > + error =3D EBADF; > + goto out; > } > =20 > /* > @@ -410,19 +405,18 @@ sys_cap_ioctls_get(struct thread *td, struct cap_io= ctls_get_args *uap) > if (cmds !=3D NULL && fdep->fde_ioctls !=3D NULL) { > error =3D copyout(fdep->fde_ioctls, cmds, > sizeof(cmds[0]) * MIN(fdep->fde_nioctls, maxcmds)); > - if (error !=3D 0) { > - FILEDESC_SUNLOCK(fdp); > - return (error); > - } > + if (error !=3D 0) > + goto out; > } > if (fdep->fde_nioctls =3D=3D -1) > td->td_retval[0] =3D INT_MAX; > else > td->td_retval[0] =3D fdep->fde_nioctls; > + error =3D 0; > =20 > +out: > FILEDESC_SUNLOCK(fdp); > - > - return (0); > + return (error); > } > =20 > /* Applied, but I removed first goto and now out label is placed before unlock. > From 0e692e05accd56a4db1f938ad7aa4c50979a6148 Mon Sep 17 00:00:00 2001 > From: Christoph Mallon > Date: Sun, 24 Feb 2013 14:00:01 +0100 > Subject: [PATCH 18/24] (Hopefully) slightly improve manpages and comments. >=20 > --- > lib/libc/gen/cap_sandboxed.3 | 6 +++--- > lib/libc/sys/cap_fcntls_limit.2 | 14 +++++++------- > lib/libc/sys/cap_ioctls_limit.2 | 24 ++++++++++++------------ > lib/libc/sys/cap_rights_limit.2 | 10 +++++----- > sys/sys/capability.h | 4 ++-- > 5 files changed, 29 insertions(+), 29 deletions(-) >=20 > diff --git a/lib/libc/gen/cap_sandboxed.3 b/lib/libc/gen/cap_sandboxed.3 > index 4896e02..067d6d2 100644 > --- a/lib/libc/gen/cap_sandboxed.3 > +++ b/lib/libc/gen/cap_sandboxed.3 > @@ -44,10 +44,10 @@ > .Fn cap_sandboxed > returns > .Va true > -is the process is in a capability mode sandbox or > +if the process is in a capability mode sandbox or > .Va false > if it is not. > -This function is more handy alternative to the > +This function is a more handy alternative to the > .Xr cap_getmode 2 > system call as it always succeeds, so there is no need for error checkin= g. > If the support for capability mode is not compiled into the kernel, > @@ -57,7 +57,7 @@ will always return > .Sh RETURN VALUES > Function > .Fn cap_sandboxed > -is always successful and can return either > +is always successful and will return either > .Va true > or > .Va false . > diff --git a/lib/libc/sys/cap_fcntls_limit.2 b/lib/libc/sys/cap_fcntls_li= mit.2 > index 38ab9cb..8fa7463 100644 > --- a/lib/libc/sys/cap_fcntls_limit.2 > +++ b/lib/libc/sys/cap_fcntls_limit.2 > @@ -44,15 +44,15 @@ > .Ft int > .Fn cap_fcntls_get "int fd" "uint32_t *fcntlrightsp" > .Sh DESCRIPTION > -If a file descriptor is granted > +If a file descriptor is granted the > .Dv CAP_FCNTL > -capability right, list of allowed > +capability right, the list of allowed > .Xr fcntl 2 > commands can be selectively reduced (but never expanded) with the > .Fn cap_fcntls_limit > system call. > .Pp > -Bitmask of allowed fcntls commands for a given file descriptor can be ob= tained > +A bitmask of allowed fcntls commands for a given file descriptor can be = obtained > with the > .Fn cap_fcntls_get > system call. > @@ -89,13 +89,13 @@ succeeds unless: > .It Bq Er EBADF > The > .Fa fd > -argument is not a valid active descriptor. > +argument is not a valid descriptor. > .It Bq Er EINVAL > An invalid flag has been passed in > .Fa fcntlrights . > .It Bq Er ENOTCAPABLE > .Fa fcntlrights > -would expand list of allowed > +would expand the list of allowed > .Xr fcntl 2 > commands. > .El > @@ -106,11 +106,11 @@ succeeds unless: > .It Bq Er EBADF > The > .Fa fd > -argument is not a valid active descriptor. > +argument is not a valid descriptor. > .It Bq Er EFAULT > The > .Fa fcntlrightsp > -argument points at invalid address. > +argument points at an invalid address. > .El > .Sh SEE ALSO > .Xr cap_ioctls_limit 2 , > diff --git a/lib/libc/sys/cap_ioctls_limit.2 b/lib/libc/sys/cap_ioctls_li= mit.2 > index 34a9bff..de524d7 100644 > --- a/lib/libc/sys/cap_ioctls_limit.2 > +++ b/lib/libc/sys/cap_ioctls_limit.2 > @@ -44,9 +44,9 @@ > .Ft ssize_t > .Fn cap_ioctls_get "int fd" "unsigned long *cmds" "size_t maxcmds" > .Sh DESCRIPTION > -If a file descriptor is granted > +If a file descriptor is granted the > .Dv CAP_IOCTL > -capability right, list of allowed > +capability right, the list of allowed > .Xr ioctl 2 > commands can be selectively reduced (but never expanded) with the > .Fn cap_ioctls_limit > @@ -62,21 +62,21 @@ There might be up to > .Va 256 > elements in the array. > .Pp > -List of allowed ioctl commands for a given file descriptor can be obtain= ed > +The list of allowed ioctl commands for a given file descriptor can be ob= tained > with the > .Fn cap_ioctls_get > system call. > The > .Fa cmds > -arguments points at the memory that can hold up to > +argument points at memory that can hold up to > .Fa maxcmds > values. > -The function populates provided buffer with up to > +The function populates the provided buffer with up to > .Fa maxcmds > -elements, but always returns total number of ioctl commands allowed for = the > +elements, but always returns the total number of ioctl commands allowed = for the > given file descriptor. > -Total number of ioctls commands for the given file descriptor can be obt= ained > -by passing > +The total number of ioctls commands for the given file descriptor can be > +obtained by passing > .Dv NULL as the > .Fa cmds > argument and > @@ -114,11 +114,11 @@ succeeds unless: > .It Bq Er EBADF > The > .Fa fd > -argument is not a valid active descriptor. > +argument is not a valid descriptor. > .It Bq Er EFAULT > The > .Fa cmds > -argument points at invalid address. > +argument points at an invalid address. > .It Bq Er EINVAL > The > .Fa ncmds > @@ -126,7 +126,7 @@ argument is greater than > .Va 256 . > .It Bq Er ENOTCAPABLE > .Fa cmds > -would expand list of allowed > +would expand the list of allowed > .Xr ioctl 2 > commands. > .El > @@ -137,7 +137,7 @@ succeeds unless: > .It Bq Er EBADF > The > .Fa fd > -argument is not a valid active descriptor. > +argument is not a valid descriptor. > .It Bq Er EFAULT > The > .Fa cmds > diff --git a/lib/libc/sys/cap_rights_limit.2 b/lib/libc/sys/cap_rights_li= mit.2 > index 2e83ea0..e2ff134 100644 > --- a/lib/libc/sys/cap_rights_limit.2 > +++ b/lib/libc/sys/cap_rights_limit.2 > @@ -68,7 +68,7 @@ Once capability rights are reduced, operations on the f= ile descriptor will be > limited to those permitted by > .Fa rights . > .Pp > -Bitmask of capability rights assigned to a file descriptor can be obtain= ed with > +A bitmask of capability rights assigned to a file descriptor can be obta= ined with > the > .Fn cap_rights_get > system call. > @@ -178,7 +178,7 @@ Note that only the > and > .Dv F_SETOWN > commands require this capability right. > -Also note that the list of permitted commands can be futher limited with= the > +Also note that the list of permitted commands can be further limited wit= h the > .Xr cap_fcntls_limit 2 > system call. > .It Dv CAP_FLOCK > @@ -254,7 +254,7 @@ Permit > .Xr ioctl 2 . > Be aware that this system call has enormous scope, including potentially > global scope for some objects. > -The list of permitted ioctl commands can be futher limited with the > +The list of permitted ioctl commands can be further limited with the > .Xr cap_ioctls_limit 2 > system call. > .\" XXXPJD: Doesn't exist anymore. > @@ -470,7 +470,7 @@ with the > .Dv O_WRONLY > flag, but without the > .Dv O_APPEND > -flag > +flag, > .Dv CAP_SEEK > is also required. > .El > @@ -503,7 +503,7 @@ argument is not a valid active descriptor. > .It Bq Er EFAULT > The > .Fa rightsp > -argument points at invalid address. > +argument points at an invalid address. > .El > .Sh SEE ALSO > .Xr accept 2 , > diff --git a/sys/sys/capability.h b/sys/sys/capability.h > index 9eed4d1..130d200 100644 > --- a/sys/sys/capability.h > +++ b/sys/sys/capability.h > @@ -267,7 +267,7 @@ int cap_enter(void); > =20 > /* > * Are we sandboxed (in capability mode)? > - * This is libc wrapper around cap_getmode(2) system call. > + * This is a libc wrapper around the cap_getmode(2) system call. > */ > _Bool cap_sandboxed(void); > =20 > @@ -289,7 +289,7 @@ int cap_rights_get(int fd, cap_rights_t *rightsp); > */ > int cap_ioctls_limit(int fd, const unsigned long *cmds, size_t ncmds); > /* > - * Returns array of allowed ioctls for the given descriptors. > + * Returns array of allowed ioctls for the given descriptor. > * If all ioctls are allowed, the cmds array is not populated and > * the function returns INT_MAX. > */ Applied. > From 2b8a154312f692912fc90bc2acd8e55ab1fc4ba4 Mon Sep 17 00:00:00 2001 > From: Christoph Mallon > Date: Sun, 24 Feb 2013 14:00:31 +0100 > Subject: [PATCH 19/24] Sort Xr. >=20 > --- > lib/libc/sys/cap_rights_limit.2 | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) >=20 > diff --git a/lib/libc/sys/cap_rights_limit.2 b/lib/libc/sys/cap_rights_li= mit.2 > index e2ff134..d8d8777 100644 > --- a/lib/libc/sys/cap_rights_limit.2 > +++ b/lib/libc/sys/cap_rights_limit.2 > @@ -546,8 +546,8 @@ argument points at an invalid address. > .Xr mq_open 2 , > .Xr open 2 , > .Xr openat 2 , > -.Xr pdgetpid 2 , > .Xr pdfork 2 , > +.Xr pdgetpid 2 , > .Xr pdkill 2 , > .Xr pdwait4 2 , > .Xr pipe 2 , Applied. > From 42aaaa14c5c1a5d96503a88a381909d6c3254727 Mon Sep 17 00:00:00 2001 > From: Christoph Mallon > Date: Sun, 24 Feb 2013 14:04:36 +0100 > Subject: [PATCH 20/24] Avoid comparing signed with unsigned values. >=20 > --- > sys/fs/nfsserver/nfs_nfsdport.c | 2 +- > sys/kern/sys_capability.c | 7 ++++--- > 2 files changed, 5 insertions(+), 4 deletions(-) >=20 > diff --git a/sys/fs/nfsserver/nfs_nfsdport.c b/sys/fs/nfsserver/nfs_nfsdp= ort.c > index 880f965..69f5629 100644 > --- a/sys/fs/nfsserver/nfs_nfsdport.c > +++ b/sys/fs/nfsserver/nfs_nfsdport.c > @@ -2775,7 +2775,7 @@ fp_getfvp(struct thread *p, int fd, struct file **f= pp, struct vnode **vpp) > int error =3D 0; > =20 > fdp =3D p->td_proc->p_fd; > - if ((u_int)fd >=3D fdp->fd_nfiles || > + if (fd < 0 || fdp->fd_nfiles <=3D fd || > (fp =3D fdp->fd_ofiles[fd].fde_file) =3D=3D NULL) { > error =3D EBADF; > goto out; > diff --git a/sys/kern/sys_capability.c b/sys/kern/sys_capability.c > index e87a4e5..e3622b0 100644 > --- a/sys/kern/sys_capability.c > +++ b/sys/kern/sys_capability.c > @@ -274,7 +274,7 @@ cap_ioctl_check(struct filedesc *fdp, int fd, u_long = cmd) > { > u_long *cmds; > ssize_t ncmds; > - u_int i; > + ssize_t i; > =20 > FILEDESC_LOCK_ASSERT(fdp); > KASSERT(fd >=3D 0 && fd < fdp->fd_nfiles, > @@ -302,12 +302,13 @@ cap_ioctl_limit_check(struct filedesc *fdp, int fd,= const u_long *cmds, > { > u_long *ocmds; > ssize_t oncmds; > - u_int i, j; > + size_t i; > + ssize_t j; > =20 > oncmds =3D fdp->fd_ofiles[fd].fde_nioctls; > if (oncmds =3D=3D -1) > return (0); > - if (oncmds < ncmds) > + if ((size_t)oncmds < ncmds) > return (ENOTCAPABLE); > =20 > ocmds =3D fdp->fd_ofiles[fd].fde_ioctls; Applied with some minor tweaks. > From a05144e19411d2b3fc8716e72ef2fad7cc9449ae Mon Sep 17 00:00:00 2001 > From: Christoph Mallon > Date: Sun, 24 Feb 2013 15:09:16 +0100 > Subject: [PATCH 21/24] For readability simplify if (x) y =3D a; else y = =3D b; with > long y to y =3D x ? a : b. >=20 > --- > sys/kern/kern_descrip.c | 10 +++------- > sys/kern/sys_capability.c | 6 ++---- > 2 files changed, 5 insertions(+), 11 deletions(-) >=20 > diff --git a/sys/kern/kern_descrip.c b/sys/kern/kern_descrip.c > index 612d51a..30dac04 100644 > --- a/sys/kern/kern_descrip.c > +++ b/sys/kern/kern_descrip.c > @@ -842,13 +842,9 @@ do_dup(struct thread *td, int flags, int old, int ne= w, > fdp->fd_ofiles[new] =3D fdp->fd_ofiles[old]; > filecaps_copy(&fdp->fd_ofiles[old].fde_caps, > &fdp->fd_ofiles[new].fde_caps); > - if ((flags & DUP_CLOEXEC) !=3D 0) { > - fdp->fd_ofiles[new].fde_flags =3D > - fdp->fd_ofiles[old].fde_flags | UF_EXCLOSE; > - } else { > - fdp->fd_ofiles[new].fde_flags =3D > - fdp->fd_ofiles[old].fde_flags & ~UF_EXCLOSE; > - } > + fdp->fd_ofiles[new].fde_flags =3D flags & DUP_CLOEXEC ? > + fdp->fd_ofiles[old].fde_flags | UF_EXCLOSE : > + fdp->fd_ofiles[old].fde_flags & ~UF_EXCLOSE; > if (new > fdp->fd_lastfile) > fdp->fd_lastfile =3D new; > *retval =3D new; > diff --git a/sys/kern/sys_capability.c b/sys/kern/sys_capability.c > index e3622b0..2306811 100644 > --- a/sys/kern/sys_capability.c > +++ b/sys/kern/sys_capability.c > @@ -409,10 +409,8 @@ sys_cap_ioctls_get(struct thread *td, struct cap_ioc= tls_get_args *uap) > if (error !=3D 0) > goto out; > } > - if (fdep->fde_nioctls =3D=3D -1) > - td->td_retval[0] =3D INT_MAX; > - else > - td->td_retval[0] =3D fdep->fde_nioctls; > + td->td_retval[0] =3D > + fdep->fde_nioctls !=3D -1 ? fdep->fde_nioctls : INT_MAX; > error =3D 0; > =20 > out: Well, IMHO my version is more readable, especially in the first case. > From 1258951ef3cdb8b8624e6a7032036e0e5e0ac8c6 Mon Sep 17 00:00:00 2001 > From: Christoph Mallon > Date: Sun, 24 Feb 2013 15:23:15 +0100 > Subject: [PATCH 22/24] Unify and simplify bitset inclusion tests. >=20 > - (have | need) !=3D have looks like a typo: shouldn't the | be a &?. Which line exactly? > - some places used (have | need) !=3D have, others (have & need) =3D=3D n= eed. > - (need & ~have) !=3D 0 -- need and not have -- is easier to comprehend. > - Avoid duplication, especially when the duplicated subexpression is long. > --- > sys/kern/kern_descrip.c | 4 ++-- > sys/kern/sys_capability.c | 11 +++++------ > usr.bin/procstat/procstat_files.c | 4 ++-- > 3 files changed, 9 insertions(+), 10 deletions(-) >=20 > diff --git a/sys/kern/kern_descrip.c b/sys/kern/kern_descrip.c > index 30dac04..64176ca 100644 > --- a/sys/kern/kern_descrip.c > +++ b/sys/kern/kern_descrip.c > @@ -1422,9 +1422,9 @@ static void > filecaps_validate(const struct filecaps *fcaps, const char *func) > { > =20 > - KASSERT((fcaps->fc_rights | CAP_MASK_VALID) =3D=3D CAP_MASK_VALID, > + KASSERT((fcaps->fc_rights & ~CAP_MASK_VALID) =3D=3D 0, > ("%s: invalid rights", func)); > - KASSERT((fcaps->fc_fcntls | CAP_FCNTL_ALL) =3D=3D CAP_FCNTL_ALL, > + KASSERT((fcaps->fc_fcntls & ~CAP_FCNTL_ALL) =3D=3D 0, > ("%s: invalid fcntls", func)); > KASSERT(fcaps->fc_fcntls =3D=3D 0 || (fcaps->fc_rights & CAP_FCNTL) != =3D 0, > ("%s: fcntls without CAP_FCNTL", func)); > diff --git a/sys/kern/sys_capability.c b/sys/kern/sys_capability.c > index 2306811..d06918c 100644 > --- a/sys/kern/sys_capability.c > +++ b/sys/kern/sys_capability.c > @@ -148,7 +148,7 @@ static inline int > _cap_check(cap_rights_t have, cap_rights_t need, enum ktr_cap_fail_type = type) > { > =20 > - if ((have | need) !=3D have) { > + if ((need & ~have) !=3D 0) { > #ifdef KTRACE > if (KTRPOINT(curthread, KTR_CAPFAIL)) > ktrcapfail(type, need, have); > @@ -215,7 +215,7 @@ sys_cap_rights_limit(struct thread *td, struct cap_ri= ghts_limit_args *uap) > AUDIT_ARG_FD(fd); > AUDIT_ARG_RIGHTS(rights); > =20 > - if ((rights | CAP_ALL) !=3D CAP_ALL) > + if ((rights & ~CAP_ALL) !=3D 0) > return (EINVAL); > =20 > fdp =3D td->td_proc->p_fd; > @@ -452,7 +452,7 @@ sys_cap_fcntls_limit(struct thread *td, struct cap_fc= ntls_limit_args *uap) > AUDIT_ARG_FD(fd); > AUDIT_ARG_FCNTL_RIGHTS(fcntlrights); > =20 > - if ((fcntlrights | CAP_FCNTL_ALL) !=3D CAP_FCNTL_ALL) > + if ((fcntlrights & ~CAP_FCNTL_ALL) !=3D 0) > return (EINVAL); > =20 > fdp =3D td->td_proc->p_fd; > @@ -463,8 +463,7 @@ sys_cap_fcntls_limit(struct thread *td, struct cap_fc= ntls_limit_args *uap) > return (EBADF); > } > =20 > - if ((fdp->fd_ofiles[fd].fde_fcntls | fcntlrights) !=3D > - fdp->fd_ofiles[fd].fde_fcntls) { > + if ((fcntlrights & ~fdp->fd_ofiles[fd].fde_fcntls) !=3D 0) { > FILEDESC_XUNLOCK(fdp); > return (ENOTCAPABLE); > } > @@ -515,7 +514,7 @@ sys_cap_new(struct thread *td, struct cap_new_args *u= ap) > AUDIT_ARG_FD(fd); > AUDIT_ARG_RIGHTS(rights); > =20 > - if ((rights | CAP_ALL) !=3D CAP_ALL) > + if ((rights & ~CAP_ALL) !=3D 0) > return (EINVAL); > =20 > fdp =3D td->td_proc->p_fd; > diff --git a/usr.bin/procstat/procstat_files.c b/usr.bin/procstat/procsta= t_files.c > index eefc5b7..16dab0b 100644 > --- a/usr.bin/procstat/procstat_files.c > +++ b/usr.bin/procstat/procstat_files.c > @@ -243,7 +243,7 @@ width_capability(cap_rights_t rights) > count =3D 0; > width =3D 0; > for (i =3D 0; i < cap_desc_count; i++) { > - if ((rights & cap_desc[i].cd_right) =3D=3D cap_desc[i].cd_right) { > + if ((cap_desc[i].cd_right & ~rights) =3D=3D 0) { > width +=3D strlen(cap_desc[i].cd_desc); > if (count) > width++; > @@ -267,7 +267,7 @@ print_capability(cap_rights_t rights, u_int capwidth) > printf("-"); > } > for (i =3D 0; i < cap_desc_count; i++) { > - if ((rights & cap_desc[i].cd_right) =3D=3D cap_desc[i].cd_right) { > + if ((cap_desc[i].cd_right & ~rights) =3D=3D 0) { > printf("%s%s", count ? "," : "", cap_desc[i].cd_desc); > width +=3D strlen(cap_desc[i].cd_desc); > if (count) Not applied for now. > From 4d721b7aa909091fc705cc8f822a13da69e1954c Mon Sep 17 00:00:00 2001 > From: Christoph Mallon > Date: Sun, 24 Feb 2013 15:33:48 +0100 > Subject: [PATCH 23/24] Simplify assertion condition, which contains a > duplicated subexpression. >=20 > --- > sys/kern/kern_descrip.c | 5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) >=20 > diff --git a/sys/kern/kern_descrip.c b/sys/kern/kern_descrip.c > index 64176ca..c2556e2 100644 > --- a/sys/kern/kern_descrip.c > +++ b/sys/kern/kern_descrip.c > @@ -1428,9 +1428,8 @@ filecaps_validate(const struct filecaps *fcaps, con= st char *func) > ("%s: invalid fcntls", func)); > KASSERT(fcaps->fc_fcntls =3D=3D 0 || (fcaps->fc_rights & CAP_FCNTL) != =3D 0, > ("%s: fcntls without CAP_FCNTL", func)); > - KASSERT(((fcaps->fc_nioctls =3D=3D -1 || fcaps->fc_nioctls =3D=3D 0) && > - fcaps->fc_ioctls =3D=3D NULL) || > - (fcaps->fc_nioctls > 0 && fcaps->fc_ioctls !=3D NULL), > + KASSERT(fcaps->fc_ioctls !=3D NULL ? fcaps->fc_nioctls > 0 : > + (fcaps->fc_nioctls =3D=3D -1 || fcaps->fc_nioctls =3D=3D 0), > ("%s: invalid ioctls", func)); > KASSERT(fcaps->fc_nioctls =3D=3D 0 || (fcaps->fc_rights & CAP_IOCTL) != =3D 0, > ("%s: ioctls without CAP_IOCTL", func)); I think my version is more readable. Skipped. > From 98dd3c8a988e043b4a8f02ed4c19d39d30e1145d Mon Sep 17 00:00:00 2001 > From: Christoph Mallon > Date: Sun, 24 Feb 2013 15:47:53 +0100 > Subject: [PATCH 24/24] Factorise code to free a file descriptor. >=20 > --- > sys/kern/kern_descrip.c | 29 +++++++++++++++++------------ > 1 file changed, 17 insertions(+), 12 deletions(-) >=20 > diff --git a/sys/kern/kern_descrip.c b/sys/kern/kern_descrip.c > index c2556e2..8256501 100644 > --- a/sys/kern/kern_descrip.c > +++ b/sys/kern/kern_descrip.c > @@ -287,6 +287,19 @@ fdunused(struct filedesc *fdp, int fd) > } > =20 > /* > + * Free a file descriptor. > + */ > +static void > +fdfree(struct filedesc *fdp, int fd) > +{ > + struct filedescent *fde =3D fdp->fd_ofiles[fd]; > + > + filecaps_free(&fde->fde_caps); > + bzero(fde, sizeof(*fde)); > + fdunused(fdp, fd); > +} > + > +/* > * System calls on descriptors. > */ > #ifndef _SYS_SYSPROTO_H_ > @@ -1165,9 +1178,7 @@ kern_close(td, fd) > FILEDESC_XUNLOCK(fdp); > return (EBADF); > } > - filecaps_free(&fdp->fd_ofiles[fd].fde_caps); > - bzero(&fdp->fd_ofiles[fd], sizeof(fdp->fd_ofiles[fd])); > - fdunused(fdp, fd); > + fdfree(fdp, fd); > =20 > /* closefp() drops the FILEDESC lock for us. */ > return (closefp(fdp, fd, fp, td, 1)); > @@ -2035,9 +2046,7 @@ setugidsafety(struct thread *td) > * NULL-out descriptor prior to close to avoid > * a race while close blocks. > */ > - filecaps_free(&fdp->fd_ofiles[i].fde_caps); > - bzero(&fdp->fd_ofiles[i], sizeof(fdp->fd_ofiles[i])); > - fdunused(fdp, i); > + fdfree(fdp, i); > FILEDESC_XUNLOCK(fdp); > (void) closef(fp, td); > FILEDESC_XLOCK(fdp); > @@ -2059,9 +2068,7 @@ fdclose(struct filedesc *fdp, struct file *fp, int = idx, struct thread *td) > =20 > FILEDESC_XLOCK(fdp); > if (fdp->fd_ofiles[idx].fde_file =3D=3D fp) { > - filecaps_free(&fdp->fd_ofiles[idx].fde_caps); > - bzero(&fdp->fd_ofiles[idx], sizeof(fdp->fd_ofiles[idx])); > - fdunused(fdp, idx); > + fdfree(fdp, idx); > FILEDESC_XUNLOCK(fdp); > fdrop(fp, td); > } else > @@ -2094,9 +2101,7 @@ fdcloseexec(struct thread *td) > fp =3D fde->fde_file; > if (fp !=3D NULL && (fp->f_type =3D=3D DTYPE_MQUEUE || > (fde->fde_flags & UF_EXCLOSE))) { > - filecaps_free(&fde->fde_caps); > - bzero(fde, sizeof(*fde)); > - fdunused(fdp, i); > + fdfree(fdp, i); > (void) closefp(fdp, i, fp, td, 0); > /* closefp() drops the FILEDESC lock. */ > FILEDESC_XLOCK(fdp); Applied. Thanks a lot! --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --yTwVabqJa5IUz21H Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlEqqWgACgkQForvXbEpPzToEACg5ZpV0c0ByzYoZ8V3zunuJ6Rt OXkAn0N0kUGsqrNrwhhQV0HL4cPQgfH3 =bm9F -----END PGP SIGNATURE----- --yTwVabqJa5IUz21H-- From owner-freebsd-arch@FreeBSD.ORG Mon Feb 25 10:35:54 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 E4BDF577 for ; Mon, 25 Feb 2013 10:35:54 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by mx1.freebsd.org (Postfix) with ESMTP id 53E92B62 for ; Mon, 25 Feb 2013 10:35:54 +0000 (UTC) Received: from mailout-de.gmx.net ([10.1.76.34]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0Mgr1C-1UVyUI139U-00M6zu for ; Mon, 25 Feb 2013 11:35:10 +0100 Received: (qmail invoked by alias); 25 Feb 2013 10:35:10 -0000 Received: from p5B131C70.dip.t-dialin.net (EHLO rotluchs.lokal) [91.19.28.112] by mail.gmx.net (mp034) with SMTP; 25 Feb 2013 11:35:10 +0100 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX19KZOZxVUhKQPEdBYAeeJH51CoMBWTXsAiAgMoRQv xvAa2zejTSinSz Message-ID: <512B3E5C.2090506@gmx.de> Date: Mon, 25 Feb 2013 11:35:08 +0100 From: Christoph Mallon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130222 Thunderbird/17.0.3 MIME-Version: 1.0 To: Pawel Jakub Dawidek Subject: Re: Large Capsicum patch for review. References: <20130213025547.GA2025@garage.freebsd.pl> <20130213230221.GB1375@garage.freebsd.pl> <20130223221116.GR1377@garage.freebsd.pl> <5129ADC5.5040306@gmx.de> <20130224193058.GW1377@garage.freebsd.pl> In-Reply-To: <20130224193058.GW1377@garage.freebsd.pl> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 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: Mon, 25 Feb 2013 10:35:55 -0000 On 24.02.2013 20:30, Pawel Jakub Dawidek wrote: > On Sun, Feb 24, 2013 at 07:05:57AM +0100, Christoph Mallon wrote: >> On 23.02.2013 23:11, Pawel Jakub Dawidek wrote: >>> On Thu, Feb 14, 2013 at 12:02:22AM +0100, Pawel Jakub Dawidek wrote: >>>> I'd like to commit this patch: >>>> >>>> http://people.freebsd.org/~pjd/patches/capkern.diff >>> >>> The patch was updated after the following changes and is available at >>> the link above: >> >> I was not able to apply this patch cleanly and had to fudge with the diff: >> - Two diff headers (contrib/openbsm/etc/audit_event and lib/libc/gen/Makefile.inc) have an extra space after --- and +++, which is recognized as part of the filename. >> Was this patch manually altered? > > Nope, but I'm using some script to generate patch(1)-compatbile diff > from a perforce diff. Ugh, why is p4 still in use, if it is just a hassle and hides history? >> - Two diffs (lib/libc/sys/cap_new.2 and sys/kern/uipc_mqueue.c) contain unexpanded $FreeBSD$ tags. >> I also had to guess, that the patch is to be applied onto r247201. >> I placed a cleaned up patch at http://tron.homeunix.org/zeug/FreeBSD/capsicum/0001-Capsicum-update.patch. >> >> This is a really big patch bomb changing lots of unrelated things. >> Do you have smaller, more managable diffs for easier review? > > I don't have smaller patch, unfortunately, but I don't think there are > unrelated things in there. Can you point me at them? The long list in your other email points out the unrealated stuff. Christoph From owner-freebsd-arch@FreeBSD.ORG Mon Feb 25 10:35:56 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 6DCBF57A for ; Mon, 25 Feb 2013 10:35:56 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by mx1.freebsd.org (Postfix) with ESMTP id B45BFB65 for ; Mon, 25 Feb 2013 10:35:55 +0000 (UTC) Received: from mailout-de.gmx.net ([10.1.76.2]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0LpihM-1UoBmk2jrS-00fOwZ for ; Mon, 25 Feb 2013 11:32:28 +0100 Received: (qmail invoked by alias); 25 Feb 2013 10:32:28 -0000 Received: from p5B131C70.dip.t-dialin.net (EHLO rotluchs.lokal) [91.19.28.112] by mail.gmx.net (mp002) with SMTP; 25 Feb 2013 11:32:28 +0100 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX1+4zAp6y9248PkhgiKym+GqtEIAun/7hAL/uNyN0a pVw8nMhbQpSmxz Message-ID: <512B3DBB.4080909@gmx.de> Date: Mon, 25 Feb 2013 11:32:27 +0100 From: Christoph Mallon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130222 Thunderbird/17.0.3 MIME-Version: 1.0 To: Pawel Jakub Dawidek Subject: Re: Large Capsicum patch for review. References: <20130213025547.GA2025@garage.freebsd.pl> <20130213230221.GB1375@garage.freebsd.pl> <20130223221116.GR1377@garage.freebsd.pl> <5129ADC5.5040306@gmx.de> <512A2CA0.2050509@gmx.de> <20130224235936.GX1377@garage.freebsd.pl> In-Reply-To: <20130224235936.GX1377@garage.freebsd.pl> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 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: Mon, 25 Feb 2013 10:35:56 -0000 On 25.02.2013 00:59, Pawel Jakub Dawidek wrote: > On Sun, Feb 24, 2013 at 04:07:12PM +0100, Christoph Mallon wrote: >> On 24.02.2013 07:05, Christoph Mallon wrote: >> - Why did you choose INT_MAX to represent "all capabilities"? >> The data type used is ssize_t, so SSIZE_MAX seems more logical. >> Further, there are several places where size_t and ssize_t come into contact, which need careful tests and casts to get right. >> Maybe it is better to always use size_t and represent "all capabilities" with SIZE_T_MAX or (size_t)-1 (which is guaranteed by C to be the maximal value). > > This is not used for capabilities, but for white-listing ioctl commands. > INT_MAX seems to just be least odd. We only allow for 256 anyway. > I could provide some dedicated define for it, eg. > > #define CAP_IOCTLS_ALL A nice name is a good step. Still, I would prefer, if consistently only one type (size_t) would be used instead of two/three (ssize_t, size_t and int for the constant). >> - Is it correct, that fdp seems to be not locked in fp_getfvp()? >> Otherweise, fget_locked() could be used instead of the manual check. > > Yeah, I don't like this too, but AFAIR it doesn't have to be locked, as > it is used by nfsd processes only that don't manipulate filedesc table. > This is at least what I recall I was told. This deserves a comment in the code. >> - I could not verify many changes, e.g. changed requested permissions, because this is just a big diff with no information about the intention of the changes. >> A series of smaller diffs with commit logs to state their intent would be really useful for reviewing. > > The entire history is in perforce, but there are many commits in there. So effectively the history is lost. > The key goals of the patch are: > > - Move from special capability descriptors that were used to keep > capability rights in the file structure to ability to configure > capability rights on any descriptor type. > > - Make capability rights more practical. > > - Allow for ioctl(2) in capability mode by providing a way to limit > permitted ioctl commands. > > - Allow for limiting permitted fcntl(2) commands. In a branch in svn one could reread these steps on every commit. Or even better, use git(-svn), which can automatically create a nice patch series (like the one I provided). >> --- a/lib/libc/gen/cap_sandboxed.c >> +++ b/lib/libc/gen/cap_sandboxed.c >> @@ -39,7 +39,7 @@ __FBSDID("$FreeBSD$"); >> bool >> cap_sandboxed(void) >> { >> - int mode; >> + u_int mode; >> >> if (cap_getmode(&mode) == -1) { >> assert(errno == ENOSYS); > > Applied, although I prefer 'unsigned int' in userland. cap_getmode() is declared with u_int, so I used it. >> --- a/lib/libc/gen/cap_sandboxed.c >> +++ b/lib/libc/gen/cap_sandboxed.c >> @@ -41,10 +41,10 @@ cap_sandboxed(void) >> { >> u_int mode; >> >> - if (cap_getmode(&mode) == -1) { >> + if (cap_getmode(&mode) != 0) { >> assert(errno == ENOSYS); >> return (false); >> } >> assert(mode == 0 || mode == 1); >> - return (mode == 1); >> + return (mode != 0); >> } > > I prefer comparison with -1, so I skipped this one. It is always suspicious, if a magic number besides 0 is used. >> From 1d1defdf7dd117afa56330c958daeac5d52be05f Mon Sep 17 00:00:00 2001 >> From: Christoph Mallon >> Date: Sun, 24 Feb 2013 13:04:41 +0100 >> Subject: [PATCH 06/24] Avoid polluting the global namespace with stdbool.h. >> >> --- >> sys/sys/capability.h | 3 +-- >> 1 file changed, 1 insertion(+), 2 deletions(-) >> >> diff --git a/sys/sys/capability.h b/sys/sys/capability.h >> index df95ae4..9eed4d1 100644 >> --- a/sys/sys/capability.h >> +++ b/sys/sys/capability.h >> @@ -251,7 +251,6 @@ int cap_fcntl_check(struct filedesc *fdp, int fd, int cmd); >> #else /* !_KERNEL */ >> >> __BEGIN_DECLS >> -#include >> >> /* >> * cap_enter(): Cause the process to enter capability mode, which will >> @@ -270,7 +269,7 @@ int cap_enter(void); >> * Are we sandboxed (in capability mode)? >> * This is libc wrapper around cap_getmode(2) system call. >> */ >> -bool cap_sandboxed(void); >> +_Bool cap_sandboxed(void); >> >> /* >> * cap_getmode(): Are we in capability mode? > > Not sure yet about this one. The manpage says, you need to include stdbool.h yourself. >> From d4c8e6bbeb678867b2bd1c0ec09faf60642465d0 Mon Sep 17 00:00:00 2001 >> From: Christoph Mallon >> Date: Sun, 24 Feb 2013 13:43:28 +0100 >> Subject: [PATCH 14/24] Avoide double test. >> >> --- >> sys/kern/sys_capability.c | 6 +++--- >> 1 file changed, 3 insertions(+), 3 deletions(-) >> >> diff --git a/sys/kern/sys_capability.c b/sys/kern/sys_capability.c >> index ecb3a6b..dbbda01 100644 >> --- a/sys/kern/sys_capability.c >> +++ b/sys/kern/sys_capability.c >> @@ -314,12 +314,12 @@ cap_ioctl_limit_check(struct filedesc *fdp, int fd, const u_long *cmds, >> >> ocmds = fdp->fd_ofiles[fd].fde_ioctls; >> for (i = 0; i < ncmds; i++) { >> - for (j = 0; j < oncmds; j++) { >> + for (j = 0;; j++) { >> + if (j == oncmds) >> + return (ENOTCAPABLE); >> if (cmds[i] == ocmds[j]) >> break; >> } >> - if (j == oncmds) >> - return (ENOTCAPABLE); >> } >> >> return (0); > > I decided to skip this one. My version is more readable, IMHO, as it is > used for other cases like TAILQ_FOREACH(), etc. where the check is > already done by the macro. The duplicate tests do not even match! You have to carefully read the code to verify, that if indeed only triggers, when the for loop terminated without break. Code duplication is almost always bad, especially if the duplicated code does not fully match. >> From 64e66277c265b3a1221d9e269c8f33345e43332c Mon Sep 17 00:00:00 2001 >> From: Christoph Mallon >> Date: Sun, 24 Feb 2013 13:49:37 +0100 >> Subject: [PATCH 17/24] Avoid code duplication on error paths. >> >> --- >> sys/kern/sys_capability.c | 42 ++++++++++++++++++------------------------ >> 1 file changed, 18 insertions(+), 24 deletions(-) >> >> diff --git a/sys/kern/sys_capability.c b/sys/kern/sys_capability.c >> index 153364b..e87a4e5 100644 >> --- a/sys/kern/sys_capability.c >> +++ b/sys/kern/sys_capability.c >> @@ -344,37 +344,32 @@ sys_cap_ioctls_limit(struct thread *td, struct cap_ioctls_limit_args *uap) >> } else { >> cmds = malloc(sizeof(cmds[0]) * ncmds, M_TEMP, M_WAITOK); >> error = copyin(uap->cmds, cmds, sizeof(cmds[0]) * ncmds); >> - if (error != 0) { >> - free(cmds, M_TEMP); >> - return (error); >> - } >> + if (error != 0) >> + goto out; >> } >> >> fdp = td->td_proc->p_fd; >> FILEDESC_XLOCK(fdp); >> >> if (fget_locked(fdp, fd) == NULL) { >> - FILEDESC_XUNLOCK(fdp); >> - free(cmds, M_TEMP); >> - return (EBADF); >> + error = EBADF; >> + goto out_locked; >> } >> >> error = cap_ioctl_limit_check(fdp, fd, cmds, ncmds); > > Applied, but I removed first goto and now out label is placed before > unlock. This leaves code duplication in place, which is error prone. >> From 42aaaa14c5c1a5d96503a88a381909d6c3254727 Mon Sep 17 00:00:00 2001 >> From: Christoph Mallon >> Date: Sun, 24 Feb 2013 14:04:36 +0100 >> Subject: [PATCH 20/24] Avoid comparing signed with unsigned values. >> >> --- >> sys/fs/nfsserver/nfs_nfsdport.c | 2 +- >> sys/kern/sys_capability.c | 7 ++++--- >> 2 files changed, 5 insertions(+), 4 deletions(-) >> >> diff --git a/sys/fs/nfsserver/nfs_nfsdport.c b/sys/fs/nfsserver/nfs_nfsdport.c >> index 880f965..69f5629 100644 >> --- a/sys/fs/nfsserver/nfs_nfsdport.c >> +++ b/sys/fs/nfsserver/nfs_nfsdport.c >> @@ -2775,7 +2775,7 @@ fp_getfvp(struct thread *p, int fd, struct file **fpp, struct vnode **vpp) >> int error = 0; >> >> fdp = p->td_proc->p_fd; >> - if ((u_int)fd >= fdp->fd_nfiles || >> + if (fd < 0 || fdp->fd_nfiles <= fd || >> (fp = fdp->fd_ofiles[fd].fde_file) == NULL) { >> error = EBADF; >> goto out; >> diff --git a/sys/kern/sys_capability.c b/sys/kern/sys_capability.c >> index e87a4e5..e3622b0 100644 >> --- a/sys/kern/sys_capability.c >> +++ b/sys/kern/sys_capability.c >> @@ -274,7 +274,7 @@ cap_ioctl_check(struct filedesc *fdp, int fd, u_long cmd) >> { >> u_long *cmds; >> ssize_t ncmds; >> - u_int i; >> + ssize_t i; >> >> FILEDESC_LOCK_ASSERT(fdp); >> KASSERT(fd >= 0 && fd < fdp->fd_nfiles, >> @@ -302,12 +302,13 @@ cap_ioctl_limit_check(struct filedesc *fdp, int fd, const u_long *cmds, >> { >> u_long *ocmds; >> ssize_t oncmds; >> - u_int i, j; >> + size_t i; >> + ssize_t j; >> >> oncmds = fdp->fd_ofiles[fd].fde_nioctls; >> if (oncmds == -1) >> return (0); >> - if (oncmds < ncmds) >> + if ((size_t)oncmds < ncmds) >> return (ENOTCAPABLE); >> >> ocmds = fdp->fd_ofiles[fd].fde_ioctls; > > Applied with some minor tweaks. Why did you mismatch the types of i and ncmds as well as j and oncmds? >> From a05144e19411d2b3fc8716e72ef2fad7cc9449ae Mon Sep 17 00:00:00 2001 >> From: Christoph Mallon >> Date: Sun, 24 Feb 2013 15:09:16 +0100 >> Subject: [PATCH 21/24] For readability simplify if (x) y = a; else y = b; with >> long y to y = x ? a : b. >> >> --- >> sys/kern/kern_descrip.c | 10 +++------- >> sys/kern/sys_capability.c | 6 ++---- >> 2 files changed, 5 insertions(+), 11 deletions(-) >> >> diff --git a/sys/kern/kern_descrip.c b/sys/kern/kern_descrip.c >> index 612d51a..30dac04 100644 >> --- a/sys/kern/kern_descrip.c >> +++ b/sys/kern/kern_descrip.c >> @@ -842,13 +842,9 @@ do_dup(struct thread *td, int flags, int old, int new, >> fdp->fd_ofiles[new] = fdp->fd_ofiles[old]; >> filecaps_copy(&fdp->fd_ofiles[old].fde_caps, >> &fdp->fd_ofiles[new].fde_caps); >> - if ((flags & DUP_CLOEXEC) != 0) { >> - fdp->fd_ofiles[new].fde_flags = >> - fdp->fd_ofiles[old].fde_flags | UF_EXCLOSE; >> - } else { >> - fdp->fd_ofiles[new].fde_flags = >> - fdp->fd_ofiles[old].fde_flags & ~UF_EXCLOSE; >> - } >> + fdp->fd_ofiles[new].fde_flags = flags & DUP_CLOEXEC ? >> + fdp->fd_ofiles[old].fde_flags | UF_EXCLOSE : >> + fdp->fd_ofiles[old].fde_flags & ~UF_EXCLOSE; >> if (new > fdp->fd_lastfile) >> fdp->fd_lastfile = new; >> *retval = new; >> diff --git a/sys/kern/sys_capability.c b/sys/kern/sys_capability.c >> index e3622b0..2306811 100644 >> --- a/sys/kern/sys_capability.c >> +++ b/sys/kern/sys_capability.c >> @@ -409,10 +409,8 @@ sys_cap_ioctls_get(struct thread *td, struct cap_ioctls_get_args *uap) >> if (error != 0) >> goto out; >> } >> - if (fdep->fde_nioctls == -1) >> - td->td_retval[0] = INT_MAX; >> - else >> - td->td_retval[0] = fdep->fde_nioctls; >> + td->td_retval[0] = >> + fdep->fde_nioctls != -1 ? fdep->fde_nioctls : INT_MAX; >> error = 0; >> >> out: > > Well, IMHO my version is more readable, especially in the first case. I had to read these lines very carefully to be sure that they actually assign to the same variables. Code duplication is really hurts readability. Maybe &fdp->fd_ofiles[old] and &fdp->fd_ofiles[new] should be placed in local variables. >> From 1258951ef3cdb8b8624e6a7032036e0e5e0ac8c6 Mon Sep 17 00:00:00 2001 >> From: Christoph Mallon >> Date: Sun, 24 Feb 2013 15:23:15 +0100 >> Subject: [PATCH 22/24] Unify and simplify bitset inclusion tests. >> >> - (have | need) != have looks like a typo: shouldn't the | be a &?. > > Which line exactly? I did /not/ say, it is a typo. I said, it /looks like/ a typo due to the | instead of the expected & in a bit test. Therefore I replaced the test by more conventional ones, which also feature less code duplication. >> - some places used (have | need) != have, others (have & need) == need. >> - (need & ~have) != 0 -- need and not have -- is easier to comprehend. >> - Avoid duplication, especially when the duplicated subexpression is long. >> --- >> sys/kern/kern_descrip.c | 4 ++-- >> sys/kern/sys_capability.c | 11 +++++------ >> usr.bin/procstat/procstat_files.c | 4 ++-- >> 3 files changed, 9 insertions(+), 10 deletions(-) >> >> diff --git a/sys/kern/kern_descrip.c b/sys/kern/kern_descrip.c >> index 30dac04..64176ca 100644 >> --- a/sys/kern/kern_descrip.c >> +++ b/sys/kern/kern_descrip.c >> @@ -1422,9 +1422,9 @@ static void >> filecaps_validate(const struct filecaps *fcaps, const char *func) >> { >> >> - KASSERT((fcaps->fc_rights | CAP_MASK_VALID) == CAP_MASK_VALID, >> + KASSERT((fcaps->fc_rights & ~CAP_MASK_VALID) == 0, >> ("%s: invalid rights", func)); >> - KASSERT((fcaps->fc_fcntls | CAP_FCNTL_ALL) == CAP_FCNTL_ALL, >> + KASSERT((fcaps->fc_fcntls & ~CAP_FCNTL_ALL) == 0, >> ("%s: invalid fcntls", func)); >> KASSERT(fcaps->fc_fcntls == 0 || (fcaps->fc_rights & CAP_FCNTL) != 0, >> ("%s: fcntls without CAP_FCNTL", func)); >> diff --git a/sys/kern/sys_capability.c b/sys/kern/sys_capability.c >> index 2306811..d06918c 100644 >> --- a/sys/kern/sys_capability.c >> +++ b/sys/kern/sys_capability.c >> @@ -148,7 +148,7 @@ static inline int >> _cap_check(cap_rights_t have, cap_rights_t need, enum ktr_cap_fail_type type) >> { >> >> - if ((have | need) != have) { >> + if ((need & ~have) != 0) { >> #ifdef KTRACE >> if (KTRPOINT(curthread, KTR_CAPFAIL)) >> ktrcapfail(type, need, have); >> From 4d721b7aa909091fc705cc8f822a13da69e1954c Mon Sep 17 00:00:00 2001 >> From: Christoph Mallon >> Date: Sun, 24 Feb 2013 15:33:48 +0100 >> Subject: [PATCH 23/24] Simplify assertion condition, which contains a >> duplicated subexpression. >> >> --- >> sys/kern/kern_descrip.c | 5 ++--- >> 1 file changed, 2 insertions(+), 3 deletions(-) >> >> diff --git a/sys/kern/kern_descrip.c b/sys/kern/kern_descrip.c >> index 64176ca..c2556e2 100644 >> --- a/sys/kern/kern_descrip.c >> +++ b/sys/kern/kern_descrip.c >> @@ -1428,9 +1428,8 @@ filecaps_validate(const struct filecaps *fcaps, const char *func) >> ("%s: invalid fcntls", func)); >> KASSERT(fcaps->fc_fcntls == 0 || (fcaps->fc_rights & CAP_FCNTL) != 0, >> ("%s: fcntls without CAP_FCNTL", func)); >> - KASSERT(((fcaps->fc_nioctls == -1 || fcaps->fc_nioctls == 0) && >> - fcaps->fc_ioctls == NULL) || >> - (fcaps->fc_nioctls > 0 && fcaps->fc_ioctls != NULL), >> + KASSERT(fcaps->fc_ioctls != NULL ? fcaps->fc_nioctls > 0 : >> + (fcaps->fc_nioctls == -1 || fcaps->fc_nioctls == 0), >> ("%s: invalid ioctls", func)); >> KASSERT(fcaps->fc_nioctls == 0 || (fcaps->fc_rights & CAP_IOCTL) != 0, >> ("%s: ioctls without CAP_IOCTL", func)); > > I think my version is more readable. Skipped. You have to read this long and split up expression very carefully, to realize, that the cases are mutually exclusive. ?: makes this immediately clear: Check two different cases, depending on whether it is a null pointer or not. Christoph From owner-freebsd-arch@FreeBSD.ORG Mon Feb 25 14:21:34 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 464E3198 for ; Mon, 25 Feb 2013 14:21:34 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ia0-x22f.google.com (ia-in-x022f.1e100.net [IPv6:2607:f8b0:4001:c02::22f]) by mx1.freebsd.org (Postfix) with ESMTP id 0F6BEF51 for ; Mon, 25 Feb 2013 14:21:34 +0000 (UTC) Received: by mail-ia0-f175.google.com with SMTP id r4so2450018iaj.6 for ; Mon, 25 Feb 2013 06:21:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=o77cpeyCCJ+TJfb/96981bIqykmaBb7nxWXzbwjWSzg=; b=fG2+Zhs9yvlk43ahGny7xobvJsxdZQEQzt3pw1XF7iph2Dd8DJuRLKbtAW2xtGT/vx ZfCBDkvjePFIjUiJoDmIc7SIf56+/o30jlskX5DnI52XcLLy+XNSYK87T9Yr5n/xnjiD UZKxxLGrG08MfjhUvsTidNNPHlJcA+Kthpg3bzxm00szawPNMZXLR8dc5KStwWAySAT8 ugLMJEYAwXAqAo9JaBd/YLGsFL9lADix9TikhveuhFuXqAyBK8+yJqmFXzaQVMwvWjyG 3kVMLia3CREnxwg1nYh131G67qm3NSmdqgva/m9H5egaVMggXXWh6zZ6f48P3bakIG04 Xi9g== X-Received: by 10.50.236.100 with SMTP id ut4mr3376944igc.86.1361802093467; Mon, 25 Feb 2013 06:21:33 -0800 (PST) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id ur12sm5410578igb.8.2013.02.25.06.21.31 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 25 Feb 2013 06:21:32 -0800 (PST) Sender: Warner Losh Subject: Re: Large Capsicum patch for review. Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <512B3E5C.2090506@gmx.de> Date: Mon, 25 Feb 2013 07:21:30 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <61FF31A0-7051-4FAE-8399-76585B1D5018@bsdimp.com> References: <20130213025547.GA2025@garage.freebsd.pl> <20130213230221.GB1375@garage.freebsd.pl> <20130223221116.GR1377@garage.freebsd.pl> <5129ADC5.5040306@gmx.de> <20130224193058.GW1377@garage.freebsd.pl> <512B3E5C.2090506@gmx.de> To: Christoph Mallon X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQlv+SehQAVMk5ql65PB6XgW0otlXzUQ3krecAQ8QppDuOTy2ONAhyWFC9buDjlp51bJWpdm 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: Mon, 25 Feb 2013 14:21:34 -0000 On Feb 25, 2013, at 3:35 AM, Christoph Mallon wrote: > On 24.02.2013 20:30, Pawel Jakub Dawidek wrote: >> On Sun, Feb 24, 2013 at 07:05:57AM +0100, Christoph Mallon wrote: >>> On 23.02.2013 23:11, Pawel Jakub Dawidek wrote: >>>> On Thu, Feb 14, 2013 at 12:02:22AM +0100, Pawel Jakub Dawidek = wrote: >>>>> I'd like to commit this patch: >>>>>=20 >>>>> http://people.freebsd.org/~pjd/patches/capkern.diff >>>>=20 >>>> The patch was updated after the following changes and is available = at >>>> the link above: >>>=20 >>> I was not able to apply this patch cleanly and had to fudge with the = diff: >>> - Two diff headers (contrib/openbsm/etc/audit_event and = lib/libc/gen/Makefile.inc) have an extra space after --- and +++, which = is recognized as part of the filename. >>> Was this patch manually altered? >>=20 >> Nope, but I'm using some script to generate patch(1)-compatbile diff >> from a perforce diff. >=20 > Ugh, why is p4 still in use, if it is just a hassle and hides history? Because it is the only VCS that doesn't suck at merging? While git, hg = and svn do a passing fair job, they all suck compared to perforce. Warner From owner-freebsd-arch@FreeBSD.ORG Mon Feb 25 21:45: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 616065F2 for ; Mon, 25 Feb 2013 21:45:20 +0000 (UTC) (envelope-from dkandula@gmail.com) Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) by mx1.freebsd.org (Postfix) with ESMTP id E8CB69AD for ; Mon, 25 Feb 2013 21:45:19 +0000 (UTC) Received: by mail-wg0-f43.google.com with SMTP id e12so2867086wge.10 for ; Mon, 25 Feb 2013 13:45:13 -0800 (PST) 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=ePZHsYypI9Qd0vPNirvQV7HSSBy1mf9Wc5TP5mJF2LA=; b=dvdsdVfzKTcfk6hq8wHuH1Msz/HoDISHLo7ejvsE5RM5GUPdzI2r6GKR3dgsrv9J7V NIj/3tYQFjqxk2Cy8JkjYI/lsKqzmh9qLuSbS3gQXfu2V9vIbuWVhOyfITBVvlYYvUNB TfjAvveWriVeJpIKP55EEpPiU0PipuBIn8ttCYcFACSkHz2WQ5C9MRDBxs2DhlxJvTCA Z1mkzJm0xFegED4NxW4PEgvqY4Wjtu6TZJ5usN/7WzFOIdqVIqgdp2p5u2P6PcLimTi9 Staa5uJ7MEqqjLvFRuTmjApVJazmBh2QR4nldpIUg49rLwrpduT2WXzJAWIXzJ+TVPh9 gTpg== MIME-Version: 1.0 X-Received: by 10.194.109.35 with SMTP id hp3mr8298105wjb.15.1361828713492; Mon, 25 Feb 2013 13:45:13 -0800 (PST) Received: by 10.194.108.104 with HTTP; Mon, 25 Feb 2013 13:45:13 -0800 (PST) Date: Mon, 25 Feb 2013 16:45:13 -0500 Message-ID: Subject: What is RN_DEBUG and where is it defined 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: Mon, 25 Feb 2013 21:45:20 -0000 Hey Can anyone tell me where RN_DEBUG is defined or what is it used for. Googling, Grepping and anything I can think of has failed. Any help is greatly appreciated. Dheeraj From owner-freebsd-arch@FreeBSD.ORG Mon Feb 25 21:49:04 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 30D0F6E6 for ; Mon, 25 Feb 2013 21:49:04 +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 91A569D5 for ; Mon, 25 Feb 2013 21:49:03 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id 45411F13; Mon, 25 Feb 2013 22:45:57 +0100 (CET) Date: Mon, 25 Feb 2013 22:50:05 +0100 From: Pawel Jakub Dawidek To: Christoph Mallon Subject: Re: Large Capsicum patch for review. Message-ID: <20130225215004.GA1375@garage.freebsd.pl> References: <20130213025547.GA2025@garage.freebsd.pl> <20130213230221.GB1375@garage.freebsd.pl> <20130223221116.GR1377@garage.freebsd.pl> <5129ADC5.5040306@gmx.de> <512A2CA0.2050509@gmx.de> <20130224235936.GX1377@garage.freebsd.pl> <512B3DBB.4080909@gmx.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VS++wcV0S1rZb1Fb" Content-Disposition: inline In-Reply-To: <512B3DBB.4080909@gmx.de> 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: Mon, 25 Feb 2013 21:49:04 -0000 --VS++wcV0S1rZb1Fb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 25, 2013 at 11:32:27AM +0100, Christoph Mallon wrote: > On 25.02.2013 00:59, Pawel Jakub Dawidek wrote: > > On Sun, Feb 24, 2013 at 04:07:12PM +0100, Christoph Mallon wrote: > >> On 24.02.2013 07:05, Christoph Mallon wrote: > >> - Why did you choose INT_MAX to represent "all capabilities"? > >> The data type used is ssize_t, so SSIZE_MAX seems more logical. > >> Further, there are several places where size_t and ssize_t come into= contact, which need careful tests and casts to get right. > >> Maybe it is better to always use size_t and represent "all capabilit= ies" with SIZE_T_MAX or (size_t)-1 (which is guaranteed by C to be the maxi= mal value). > >=20 > > This is not used for capabilities, but for white-listing ioctl commands. > > INT_MAX seems to just be least odd. We only allow for 256 anyway. > > I could provide some dedicated define for it, eg. > >=20 > > #define CAP_IOCTLS_ALL >=20 > A nice name is a good step. > Still, I would prefer, if consistently only one type (size_t) would be us= ed instead of two/three (ssize_t, size_t and int for the constant). Using three types here is not inconsistent, it is a common practise. Check out even read(2) and write(2) - they take size as size_t, as there is no need for a negative size, but they return ssize_t, because they can return -1 if an error occured. This is exactly what I do in cap_ioctls_get(). I use size_t as this is preferred type for size, but I don't need size_t for iterator, because I know the value will never need more than 16 bits, so I use int as a more CPU-friendly type. > >> - Is it correct, that fdp seems to be not locked in fp_getfvp()? > >> Otherweise, fget_locked() could be used instead of the manual check. > >=20 > > Yeah, I don't like this too, but AFAIR it doesn't have to be locked, as > > it is used by nfsd processes only that don't manipulate filedesc table. > > This is at least what I recall I was told. >=20 > This deserves a comment in the code. I agree. Not my code, though. > >> - I could not verify many changes, e.g. changed requested permissions,= because this is just a big diff with no information about the intention of= the changes. > >> A series of smaller diffs with commit logs to state their intent wou= ld be really useful for reviewing. > >=20 > > The entire history is in perforce, but there are many commits in there. >=20 > So effectively the history is lost. The entire history is there, nothing is lost: http://p4db.freebsd.org/ > > The key goals of the patch are: > >=20 > > - Move from special capability descriptors that were used to keep > > capability rights in the file structure to ability to configure > > capability rights on any descriptor type. > >=20 > > - Make capability rights more practical. > >=20 > > - Allow for ioctl(2) in capability mode by providing a way to limit > > permitted ioctl commands. > >=20 > > - Allow for limiting permitted fcntl(2) commands. >=20 > In a branch in svn one could reread these steps on every commit. > Or even better, use git(-svn), which can automatically create a nice patc= h series (like the one I provided). Your changes were pretty simple, so they look nice as separate commits. The patch you review is a result of ~2 months of work and exporting every single change would not create such nice output. If those changes were implemented totally separated, I could generate several independent patches, but those changes were implemented together and trying to separate them now would be, if possible, very time consuming. So eventhough I agree it would be easier to review them separately, I only have this single patch. > >> --- a/lib/libc/gen/cap_sandboxed.c > >> +++ b/lib/libc/gen/cap_sandboxed.c > >> @@ -39,7 +39,7 @@ __FBSDID("$FreeBSD$"); > >> bool > >> cap_sandboxed(void) > >> { > >> - int mode; > >> + u_int mode; > >> =20 > >> if (cap_getmode(&mode) =3D=3D -1) { > >> assert(errno =3D=3D ENOSYS); > >=20 > > Applied, although I prefer 'unsigned int' in userland. >=20 > cap_getmode() is declared with u_int, so I used it. Hmm, I wanted to change cap_getmode(2) argument to 'unsigned int', but many syscalls (at least as defined in syscalls.master) use u_int/u_long, eventhough they are sometimes documented differently, eg. ioctl(2). > >> --- a/lib/libc/gen/cap_sandboxed.c > >> +++ b/lib/libc/gen/cap_sandboxed.c > >> @@ -41,10 +41,10 @@ cap_sandboxed(void) > >> { > >> u_int mode; > >> =20 > >> - if (cap_getmode(&mode) =3D=3D -1) { > >> + if (cap_getmode(&mode) !=3D 0) { > >> assert(errno =3D=3D ENOSYS); > >> return (false); > >> } > >> assert(mode =3D=3D 0 || mode =3D=3D 1); > >> - return (mode =3D=3D 1); > >> + return (mode !=3D 0); > >> } > >=20 > > I prefer comparison with -1, so I skipped this one. >=20 > It is always suspicious, if a magic number besides 0 is used. Not really. Majority of syscalls returns exactly -1 on error. The manual page says -1 on error, not something other than 0, although on the other hand it only returns 0 on success. I agree that in most cases it is better to check against 0 - if a syscall will suddenly start to return something other than 0 and -1, it is better to assume failure. In this very case we want to return true only if we are very sure the process is in sandbox in case it wants to execute some risky code based on the fact if it is in sandbox or not, so something like this would be best: if (cap_getmode(&mode) !=3D 0) { assert(errno =3D=3D ENOSYS); return (false); } assert(mode =3D=3D 0 || mode =3D=3D 1); return (mode =3D=3D 1); We return 'false' if cap_getmode() returns -1 or any unexpected value (your version), but we then return 'false' when 'mode' is either 0 or any unexpected number (my version). > >> --- a/sys/sys/capability.h > >> +++ b/sys/sys/capability.h > >> @@ -251,7 +251,6 @@ int cap_fcntl_check(struct filedesc *fdp, int fd, = int cmd); > >> #else /* !_KERNEL */ > >> =20 > >> __BEGIN_DECLS > >> -#include > >> =20 > >> /* > >> * cap_enter(): Cause the process to enter capability mode, which will > >> @@ -270,7 +269,7 @@ int cap_enter(void); > >> * Are we sandboxed (in capability mode)? > >> * This is libc wrapper around cap_getmode(2) system call. > >> */ > >> -bool cap_sandboxed(void); > >> +_Bool cap_sandboxed(void); > >> =20 > >> /* > >> * cap_getmode(): Are we in capability mode? > >=20 > > Not sure yet about this one. >=20 > The manpage says, you need to include stdbool.h yourself. I'm waiting for an opinion on this from one person still. > >> --- a/sys/kern/sys_capability.c > >> +++ b/sys/kern/sys_capability.c > >> @@ -314,12 +314,12 @@ cap_ioctl_limit_check(struct filedesc *fdp, int = fd, const u_long *cmds, > >> =20 > >> ocmds =3D fdp->fd_ofiles[fd].fde_ioctls; > >> for (i =3D 0; i < ncmds; i++) { > >> - for (j =3D 0; j < oncmds; j++) { > >> + for (j =3D 0;; j++) { > >> + if (j =3D=3D oncmds) > >> + return (ENOTCAPABLE); > >> if (cmds[i] =3D=3D ocmds[j]) > >> break; > >> } > >> - if (j =3D=3D oncmds) > >> - return (ENOTCAPABLE); > >> } > >> =20 > >> return (0); > >=20 > > I decided to skip this one. My version is more readable, IMHO, as it is > > used for other cases like TAILQ_FOREACH(), etc. where the check is > > already done by the macro. >=20 > The duplicate tests do not even match! > You have to carefully read the code to verify, that if indeed only trigge= rs, when the for loop terminated without break. > Code duplication is almost always bad, especially if the duplicated code = does not fully match. I don't agree, sorry. Your loop looks like endless loop at first. If the loop would be more complex, it would be hard to tell at first glance if the loop even terminates. For me it looks awkward - there is a place in 'for ()' for a check, which defines when the loop should end; IMHO it is there for a reason. The construction I use is widely used, at least in FreeBSD code and looks obvious to me. > >> --- a/sys/kern/sys_capability.c > >> +++ b/sys/kern/sys_capability.c > >> @@ -344,37 +344,32 @@ sys_cap_ioctls_limit(struct thread *td, struct c= ap_ioctls_limit_args *uap) > >> } else { > >> cmds =3D malloc(sizeof(cmds[0]) * ncmds, M_TEMP, M_WAITOK); > >> error =3D copyin(uap->cmds, cmds, sizeof(cmds[0]) * ncmds); > >> - if (error !=3D 0) { > >> - free(cmds, M_TEMP); > >> - return (error); > >> - } > >> + if (error !=3D 0) > >> + goto out; > >> } > >> =20 > >> fdp =3D td->td_proc->p_fd; > >> FILEDESC_XLOCK(fdp); > >> =20 > >> if (fget_locked(fdp, fd) =3D=3D NULL) { > >> - FILEDESC_XUNLOCK(fdp); > >> - free(cmds, M_TEMP); > >> - return (EBADF); > >> + error =3D EBADF; > >> + goto out_locked; > >> } > >> =20 > >> error =3D cap_ioctl_limit_check(fdp, fd, cmds, ncmds); > >=20 > > Applied, but I removed first goto and now out label is placed before > > unlock. >=20 > This leaves code duplication in place, which is error prone. But eliminates extra goto label that is used for exactly one case. Once we grow at least one more error condition that doesn't need unlocking and I'm fine with adding it. > >> --- a/sys/kern/sys_capability.c > >> +++ b/sys/kern/sys_capability.c > >> @@ -274,7 +274,7 @@ cap_ioctl_check(struct filedesc *fdp, int fd, u_lo= ng cmd) > >> { > >> u_long *cmds; > >> ssize_t ncmds; > >> - u_int i; > >> + ssize_t i; > >> =20 > >> FILEDESC_LOCK_ASSERT(fdp); > >> KASSERT(fd >=3D 0 && fd < fdp->fd_nfiles, > >> @@ -302,12 +302,13 @@ cap_ioctl_limit_check(struct filedesc *fdp, int = fd, const u_long *cmds, > >> { > >> u_long *ocmds; > >> ssize_t oncmds; > >> - u_int i, j; > >> + size_t i; > >> + ssize_t j; > >> =20 > >> oncmds =3D fdp->fd_ofiles[fd].fde_nioctls; > >> if (oncmds =3D=3D -1) > >> return (0); > >> - if (oncmds < ncmds) > >> + if ((size_t)oncmds < ncmds) > >> return (ENOTCAPABLE); > >> =20 > >> ocmds =3D fdp->fd_ofiles[fd].fde_ioctls; > >=20 > > Applied with some minor tweaks. >=20 > Why did you mismatch the types of i and ncmds as well as j and oncmds? I use 'int' to compare with 'ssize_t' and 'u_int' to compare with 'size_t'. I tried to explain this at the begining of my e-mail. > >> --- a/sys/kern/kern_descrip.c > >> +++ b/sys/kern/kern_descrip.c > >> @@ -842,13 +842,9 @@ do_dup(struct thread *td, int flags, int old, int= new, > >> fdp->fd_ofiles[new] =3D fdp->fd_ofiles[old]; > >> filecaps_copy(&fdp->fd_ofiles[old].fde_caps, > >> &fdp->fd_ofiles[new].fde_caps); > >> - if ((flags & DUP_CLOEXEC) !=3D 0) { > >> - fdp->fd_ofiles[new].fde_flags =3D > >> - fdp->fd_ofiles[old].fde_flags | UF_EXCLOSE; > >> - } else { > >> - fdp->fd_ofiles[new].fde_flags =3D > >> - fdp->fd_ofiles[old].fde_flags & ~UF_EXCLOSE; > >> - } > >> + fdp->fd_ofiles[new].fde_flags =3D flags & DUP_CLOEXEC ? > >> + fdp->fd_ofiles[old].fde_flags | UF_EXCLOSE : > >> + fdp->fd_ofiles[old].fde_flags & ~UF_EXCLOSE; > >> if (new > fdp->fd_lastfile) > >> fdp->fd_lastfile =3D new; > >> *retval =3D new; > >> diff --git a/sys/kern/sys_capability.c b/sys/kern/sys_capability.c > >> index e3622b0..2306811 100644 > >> --- a/sys/kern/sys_capability.c > >> +++ b/sys/kern/sys_capability.c > >> @@ -409,10 +409,8 @@ sys_cap_ioctls_get(struct thread *td, struct cap_= ioctls_get_args *uap) > >> if (error !=3D 0) > >> goto out; > >> } > >> - if (fdep->fde_nioctls =3D=3D -1) > >> - td->td_retval[0] =3D INT_MAX; > >> - else > >> - td->td_retval[0] =3D fdep->fde_nioctls; > >> + td->td_retval[0] =3D > >> + fdep->fde_nioctls !=3D -1 ? fdep->fde_nioctls : INT_MAX; > >> error =3D 0; > >> =20 > >> out: > >=20 > > Well, IMHO my version is more readable, especially in the first case. >=20 > I had to read these lines very carefully to be sure that they actually as= sign to the same variables. > Code duplication is really hurts readability. Trying to squeeze as much as possible into one line and then breaking the line into three doesn't cure readability either, IMHO. It's probably a matter of taste, but my version is more readable for me. > Maybe &fdp->fd_ofiles[old] and &fdp->fd_ofiles[new] should be placed in l= ocal variables. Good idea, see: http://p4db.freebsd.org/changeView.cgi?CH=3D222366 > >> From 1258951ef3cdb8b8624e6a7032036e0e5e0ac8c6 Mon Sep 17 00:00:00 2001 > >> From: Christoph Mallon > >> Date: Sun, 24 Feb 2013 15:23:15 +0100 > >> Subject: [PATCH 22/24] Unify and simplify bitset inclusion tests. > >> > >> - (have | need) !=3D have looks like a typo: shouldn't the | be a &?. > >=20 > > Which line exactly? >=20 > I did /not/ say, it is a typo. > I said, it /looks like/ a typo due to the | instead of the expected & in = a bit test. > Therefore I replaced the test by more conventional ones, which also featu= re less code duplication. To be honest I was a bit confused by it initially too. This is something that was there when I came and I decided to left it that way, but I think you convinced me to use more common construct. I applied your changes. > >> From 4d721b7aa909091fc705cc8f822a13da69e1954c Mon Sep 17 00:00:00 2001 > >> From: Christoph Mallon > >> Date: Sun, 24 Feb 2013 15:33:48 +0100 > >> Subject: [PATCH 23/24] Simplify assertion condition, which contains a > >> duplicated subexpression. > >> > >> --- > >> sys/kern/kern_descrip.c | 5 ++--- > >> 1 file changed, 2 insertions(+), 3 deletions(-) > >> > >> diff --git a/sys/kern/kern_descrip.c b/sys/kern/kern_descrip.c > >> index 64176ca..c2556e2 100644 > >> --- a/sys/kern/kern_descrip.c > >> +++ b/sys/kern/kern_descrip.c > >> @@ -1428,9 +1428,8 @@ filecaps_validate(const struct filecaps *fcaps, = const char *func) > >> ("%s: invalid fcntls", func)); > >> KASSERT(fcaps->fc_fcntls =3D=3D 0 || (fcaps->fc_rights & CAP_FCNTL) = !=3D 0, > >> ("%s: fcntls without CAP_FCNTL", func)); > >> - KASSERT(((fcaps->fc_nioctls =3D=3D -1 || fcaps->fc_nioctls =3D=3D 0)= && > >> - fcaps->fc_ioctls =3D=3D NULL) || > >> - (fcaps->fc_nioctls > 0 && fcaps->fc_ioctls !=3D NULL), > >> + KASSERT(fcaps->fc_ioctls !=3D NULL ? fcaps->fc_nioctls > 0 : > >> + (fcaps->fc_nioctls =3D=3D -1 || fcaps->fc_nioctls =3D=3D 0), > >> ("%s: invalid ioctls", func)); > >> KASSERT(fcaps->fc_nioctls =3D=3D 0 || (fcaps->fc_rights & CAP_IOCTL)= !=3D 0, > >> ("%s: ioctls without CAP_IOCTL", func)); > >=20 > > I think my version is more readable. Skipped. >=20 > You have to read this long and split up expression very carefully, to rea= lize, that the cases are mutually exclusive. > ?: makes this immediately clear: Check two different cases, depending on = whether it is a null pointer or not. Ok, I applied your change, after looking at it more it definiately is simpler, although I don't think ?:'s result is boolean, but that's not a big deal. I updated the patch: http://people.freebsd.org/~pjd/patches/capkern.diff --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --VS++wcV0S1rZb1Fb Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlEr3IwACgkQForvXbEpPzS1GACeJy9ICJurBesfMiY1UX01R1c3 dDMAn2Qtwdn3RwxWe2gVL8aBEirmIVbZ =Y+H4 -----END PGP SIGNATURE----- --VS++wcV0S1rZb1Fb-- From owner-freebsd-arch@FreeBSD.ORG Mon Feb 25 22:11:43 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 8F5C0E17 for ; Mon, 25 Feb 2013 22:11:43 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by mx1.freebsd.org (Postfix) with ESMTP id 5C538ACE for ; Mon, 25 Feb 2013 22:11:42 +0000 (UTC) Received: from c-24-8-232-202.hsd1.co.comcast.net ([24.8.232.202] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1UA6Gr-0003kC-Fx; Mon, 25 Feb 2013 22:11:41 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r1PMBdFG081244; Mon, 25 Feb 2013 15:11:39 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.232.202 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19Th8ke716ofdg9pVOjIg+U Subject: Re: What is RN_DEBUG and where is it defined From: Ian Lepore To: Dheeraj Kandula In-Reply-To: References: Content-Type: text/plain; charset="us-ascii" Date: Mon, 25 Feb 2013 15:11:39 -0700 Message-ID: <1361830299.16937.95.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit 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: Mon, 25 Feb 2013 22:11:43 -0000 On Mon, 2013-02-25 at 16:45 -0500, Dheeraj Kandula wrote: > Hey > Can anyone tell me where RN_DEBUG is defined or what is it used for. > Googling, Grepping and anything I can think of has failed. > > Any help is greatly appreciated. > Checking the "svn annotate" for some of the places the symbol is used, it looks like it came from an original BSD 4.4 source import many years ago. There may have been some mechanism (such as a kernel option) for setting it in that build environment which didn't get propagated to the freebsd tree. -- Ian From owner-freebsd-arch@FreeBSD.ORG Tue Feb 26 10:43:15 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 27249478; Tue, 26 Feb 2013 10:43:15 +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 DCC0DADB; Tue, 26 Feb 2013 10:43:14 +0000 (UTC) Received: from ds4.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id E46BAAAB7; Tue, 26 Feb 2013 10:43:12 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id A66719A37; Tue, 26 Feb 2013 11:43:12 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Pawel Jakub Dawidek Subject: Re: Large Capsicum patch for review. References: <20130213025547.GA2025@garage.freebsd.pl> <20130213230221.GB1375@garage.freebsd.pl> <20130223221116.GR1377@garage.freebsd.pl> <5129ADC5.5040306@gmx.de> <512A2CA0.2050509@gmx.de> <20130224235936.GX1377@garage.freebsd.pl> <512B3DBB.4080909@gmx.de> <20130225215004.GA1375@garage.freebsd.pl> Date: Tue, 26 Feb 2013 11:43:12 +0100 In-Reply-To: <20130225215004.GA1375@garage.freebsd.pl> (Pawel Jakub Dawidek's message of "Mon, 25 Feb 2013 22:50:05 +0100") Message-ID: <867glvbbjz.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: Christoph Mallon , 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: Tue, 26 Feb 2013 10:43:15 -0000 Pawel Jakub Dawidek writes: > I use size_t as this is preferred type for size, but I don't need size_t > for iterator, because I know the value will never need more than 16 > bits, so I use int as a more CPU-friendly type. Using int as an iterator can lead to warnings about signedness mismatch in loop conditions etc., so you should at the very least use unsigned int. Besides, size_t is equal to unsigned long on all platforms, so "CPU-friendly" is not a valid argument. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Tue Feb 26 12:12: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 1CF21761 for ; Tue, 26 Feb 2013 12:12: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 C0F57ED0 for ; Tue, 26 Feb 2013 12:12:32 +0000 (UTC) Received: from localhost (58.wheelsystems.com [83.12.187.58]) by mail.dawidek.net (Postfix) with ESMTPSA id 9E5D6F7; Tue, 26 Feb 2013 13:09:31 +0100 (CET) Date: Tue, 26 Feb 2013 13:13:46 +0100 From: Pawel Jakub Dawidek To: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= Subject: Re: Large Capsicum patch for review. Message-ID: <20130226121345.GB1341@garage.freebsd.pl> References: <20130213025547.GA2025@garage.freebsd.pl> <20130213230221.GB1375@garage.freebsd.pl> <20130223221116.GR1377@garage.freebsd.pl> <5129ADC5.5040306@gmx.de> <512A2CA0.2050509@gmx.de> <20130224235936.GX1377@garage.freebsd.pl> <512B3DBB.4080909@gmx.de> <20130225215004.GA1375@garage.freebsd.pl> <867glvbbjz.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="l76fUT7nc3MelDdI" Content-Disposition: inline In-Reply-To: <867glvbbjz.fsf@ds4.des.no> X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Christoph Mallon , 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: Tue, 26 Feb 2013 12:12:33 -0000 --l76fUT7nc3MelDdI Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Feb 26, 2013 at 11:43:12AM +0100, Dag-Erling Sm=F8rgrav wrote: > Pawel Jakub Dawidek writes: > > I use size_t as this is preferred type for size, but I don't need size_t > > for iterator, because I know the value will never need more than 16 > > bits, so I use int as a more CPU-friendly type. >=20 > Using int as an iterator can lead to warnings about signedness mismatch > in loop conditions etc., so you should at the very least use unsigned > int. [...] I use 'int' for 'ssize_t' and 'unsigned int' for 'size_t'. > [...] Besides, size_t is equal to unsigned long on all platforms, so > "CPU-friendly" is not a valid argument. Is long more CPU-friendly than int? --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --l76fUT7nc3MelDdI Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlEspvkACgkQForvXbEpPzSmewCgkcEYPerjF8rVacHrEtuvmhF6 P7cAoMp0Zfht4n4XpmEohu877RNbv65O =yhfr -----END PGP SIGNATURE----- --l76fUT7nc3MelDdI-- From owner-freebsd-arch@FreeBSD.ORG Tue Feb 26 12:24:07 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 BF3399EB; Tue, 26 Feb 2013 12:24:07 +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 81A70F38; Tue, 26 Feb 2013 12:24:07 +0000 (UTC) Received: from ds4.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id 5CDB0AB51; Tue, 26 Feb 2013 12:24:06 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 1B9859A49; Tue, 26 Feb 2013 13:24:06 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Pawel Jakub Dawidek Subject: Re: Large Capsicum patch for review. References: <20130213025547.GA2025@garage.freebsd.pl> <20130213230221.GB1375@garage.freebsd.pl> <20130223221116.GR1377@garage.freebsd.pl> <5129ADC5.5040306@gmx.de> <512A2CA0.2050509@gmx.de> <20130224235936.GX1377@garage.freebsd.pl> <512B3DBB.4080909@gmx.de> <20130225215004.GA1375@garage.freebsd.pl> <867glvbbjz.fsf@ds4.des.no> <20130226121345.GB1341@garage.freebsd.pl> Date: Tue, 26 Feb 2013 13:24:05 +0100 In-Reply-To: <20130226121345.GB1341@garage.freebsd.pl> (Pawel Jakub Dawidek's message of "Tue, 26 Feb 2013 13:13:46 +0100") Message-ID: <86y5eb9sbe.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: Christoph Mallon , 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: Tue, 26 Feb 2013 12:24:07 -0000 Pawel Jakub Dawidek writes: > Dag-Erling Sm=C3=B8rgrav writes: > > Pawel Jakub Dawidek writes: > > > [...] I use int as a more CPU-friendly type [than size_t] > > [...] size_t is equal to unsigned long on all platforms, so > > "CPU-friendly" is not a valid argument. > Is long more CPU-friendly than int? No, but it isn't any *less* CPU-friendly either, so this is not a valid argument for choosing unsigned int over size_t. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Wed Feb 27 00:35: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 7E7D5D3C for ; Wed, 27 Feb 2013 00:35:22 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) by mx1.freebsd.org (Postfix) with ESMTP id 979FDD4B for ; Wed, 27 Feb 2013 00:35:20 +0000 (UTC) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.5/8.14.5) with ESMTP id r1R0ZHTq010099 for ; Tue, 26 Feb 2013 18:35:17 -0600 (CST) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.5/8.14.5/Submit) id r1R0ZHuZ010098 for freebsd-arch@freebsd.org; Tue, 26 Feb 2013 18:35:17 -0600 (CST) (envelope-from brooks) Date: Tue, 26 Feb 2013 18:35:17 -0600 From: Brooks Davis To: freebsd-arch@freebsd.org Subject: [RFC] external compiler support Message-ID: <20130227003517.GB7348@lor.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/NkBOFFp2J2Af1nK" Content-Disposition: inline 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: Wed, 27 Feb 2013 00:35:22 -0000 --/NkBOFFp2J2Af1nK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Below (and at http://people.freebsd.org/~brooks/patches/xcc.diff) you can find an initial patch with proposed commit for external compiler support. It relies on the existing cross binutils as I'm finding that the two are fairly separable. With this patch I've been able to build =66rom amd64 to arm, amd64, and i386 using clang from the lang/clang-devel port. I've also compiled the tree with a customized clang being developed at the University of Cambridge. The patch is untested with gcc. Does this seem like a reasonable approach? I do plan to look at external binutils support, but it's not on the critical path for our current work so I've opted to avoid it for now. As a bonus for those who don't need an external compiler, but do run make buildworld frequently, the XCC, XCXX, and XCPP variables can be set to the location of the installed base system compiler to avoid building the compiler twice during buildworld. -- Brooks ----- MFP4 222356, 222371, 222375, 222391, 222403, 222407, 222411 Add support for an external cross compiler. The cross compiler is specified by passing the XCC, XCXX, and XCPP variables (corresponding to CC, CXX, and CPP) to buildworld/buildkernel. The compiler must be clang or be configured to target the appropriate architecture. To speed build times, if XCC is an absolute path or WITHOUT_CROSS_COMPILER is defined then no cross compiler will be built during the cross-tools stage. To facilitate the use of unmodified external compilers, a WITHOUT_FORMAT_EXTENSIONS option is available to supress printf format checking. As a short-term measure, supress a few new clang warnings during kernel builds. Sponsored by: DARPA, AFRL Reviewed by: xxx --- ../../freebsd/src/Makefile.inc1 2013-02-26 21:31:09.000000000 +0000 +++ ./Makefile.inc1 2013-02-26 21:10:50.000000000 +0000 @@ -280,16 +280,34 @@ .if ${MK_CDDL} =3D=3D "no" WMAKEENV+=3D NO_CTF=3D1 .endif -.if ${CC:T:Mgcc} =3D=3D "gcc" +XCC?=3D ${CC} +XCXX?=3D ${CXX} +XCPP?=3D ${CPP} +.if ${XCC:T:Mgcc} =3D=3D "gcc" WMAKE_COMPILER_TYPE=3D gcc -.elif ${CC:T:Mclang} =3D=3D "clang" +.elif ${XCC:T:Mclang} =3D=3D "clang" WMAKE_COMPILER_TYPE=3D clang .elif ${MK_CLANG_IS_CC} =3D=3D "no" WMAKE_COMPILER_TYPE=3D gcc .else WMAKE_COMPILER_TYPE=3D clang .endif -WMAKEENV+=3D COMPILER_TYPE=3D${WMAKE_COMPILER_TYPE} +.if ${XCC:M/*} +XFLAGS=3D --sysroot=3D${WORLDTMP} -B${WORLDTMP}/usr/bin +.if ${TARGET_ARCH} !=3D ${MACHINE_ARCH} && ${WMAKE_COMPILER_TYPE} =3D=3D "= clang" +.if (${TARGET_ARCH} =3D=3D "arm" || ${TARGET_ARCH} =3D=3D "armv6") && \ +${MK_ARM_EABI} !=3D "no" +TARGET_ABI=3D gnueabi +.else +TARGET_ABI=3D unknown +.endif +TARGET_TRIPLE?=3D ${TARGET_ARCH:C/amd64/x86_64/}-${TARGET_ABI}-freebsd10.0 +XFLAGS+=3D -target ${TARGET_TRIPLE} +.endif +.endif +WMAKEENV+=3D CC=3D"${XCC} ${XFLAGS}" CXX=3D"${XCXX} ${XFLAGS}" \ + CPP=3D"${XCPP} ${XFLAGS}" \ + COMPILER_TYPE=3D${WMAKE_COMPILER_TYPE} WMAKE=3D ${WMAKEENV} ${MAKE} ${WORLD_FLAGS} -f Makefile.inc1 DESTDIR=3D${= WORLDTMP} =20 .if ${TARGET_ARCH} =3D=3D "amd64" || ${TARGET_ARCH} =3D=3D "powerpc64" @@ -321,6 +339,7 @@ =20 =20 LIB32FLAGS=3D -m32 ${LIB32CPUFLAGS} -DCOMPAT_32BIT \ + --sysroot=3D${WORLDTMP} \ -isystem ${LIB32TMP}/usr/include/ \ -L${LIB32TMP}/usr/lib32 \ -B${LIB32TMP}/usr/lib32 @@ -336,8 +355,8 @@ SHLIBDIR=3D/usr/lib32 \ COMPILER_TYPE=3D${WMAKE_COMPILER_TYPE} LIB32WMAKEFLAGS+=3D \ - CC=3D"${CC} ${LIB32FLAGS}" \ - CXX=3D"${CXX} ${LIB32FLAGS}" \ + CC=3D"${XCC} ${LIB32FLAGS}" \ + CXX=3D"${XCXX} ${LIB32FLAGS}" \ DESTDIR=3D${LIB32TMP} \ -DCOMPAT_32BIT \ -DLIBRARIES_ONLY \ @@ -1288,6 +1307,9 @@ _binutils=3D gnu/usr.bin/binutils .endif =20 +# If an full path to an external cross compiler is given, don't build +# a cross compiler. +.if ${XCC:M/*} =3D=3D "" && ${MK_CROSS_COMPILER} !=3D "no" .if ${MK_CLANG} !=3D "no" && (${MK_CLANG_IS_CC} !=3D "no" || ${CC:T:Mclang= } =3D=3D "clang") _clang=3D usr.bin/clang _clang_libs=3D lib/clang @@ -1296,6 +1318,7 @@ .if ${MK_GCC} !=3D "no" && (${MK_CLANG_IS_CC} =3D=3D "no" || ${TARGET} =3D= =3D "pc98") _cc=3D gnu/usr.bin/cc .endif +.endif =20 cross-tools: .for _tool in \ --- ../../freebsd/src/share/mk/bsd.own.mk 2013-02-15 18:49:13.000000000 +00= 00 +++ share/mk/bsd.own.mk 2013-02-26 21:10:50.000000000 +0000 @@ -262,6 +262,7 @@ CAPSICUM \ CDDL \ CPP \ + CROSS_COMPILER \ CRYPT \ CTM \ CVS \ @@ -271,6 +272,7 @@ ED_CRYPTO \ EXAMPLES \ FLOPPY \ + FORMAT_EXTENSIONS \ FORTH \ FP_LIBC \ FREEBSD_UPDATE \ --- ../../freebsd/src/sys/conf/kern.mk 2012-11-11 22:15:16.000000000 +0000 +++ sys/conf/kern.mk 2013-02-26 20:35:48.000000000 +0000 @@ -5,7 +5,7 @@ # CWARNFLAGS?=3D -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototype= s \ -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual \ - -Wundef -Wno-pointer-sign -fformat-extensions \ + -Wundef -Wno-pointer-sign ${FORMAT_EXTENTIONS} \ -Wmissing-include-dirs -fdiagnostics-show-option \ ${CWARNEXTRA} # @@ -29,7 +29,18 @@ # enough to error out the whole kernel build. Display them anyway, so the= re is # some incentive to fix them eventually. CWARNEXTRA?=3D -Wno-error-tautological-compare -Wno-error-empty-body \ - -Wno-error-parentheses-equality + -Wno-error-parentheses-equality \ + -Wno-sizeof-pointer-memaccess \ + -Wno-unused-command-line-argument \ + ${NO_WFORMAT} +.endif + +# External compilers may not support our format extensions. Allow them +# to be disabled. WARNING: format checking is disabled in this case. +.if ${MK_FORMAT_EXTENSIONS} =3D=3D "no" +NO_WFORMAT=3D -Wno-format +.else +FORMAT_EXTENTIONS=3D -fformat-extensions .endif =20 # diff -uN ../../freebsd/src/tools/build/options/WITHOUT_CROSS_COMPILER tools= /build/options/WITHOUT_CROSS_COMPILER --- ../../freebsd/src/tools/build/options/WITHOUT_CROSS_COMPILER 1970-01-01= 00:00:00.000000000 +0000 +++ tools/build/options/WITHOUT_CROSS_COMPILER 2013-02-26 21:10:50.00000000= 0 +0000 @@ -0,0 +1,3 @@ +.\" $FreeBSD$ +Set to not build a cross compiler in the cross-tools stage of +buildworld, buildkernel, etc. diff -uN ../../freebsd/src/tools/build/options/WITHOUT_FORMAT_EXTENSIONS to= ols/build/options/WITHOUT_FORMAT_EXTENSIONS --- ../../freebsd/src/tools/build/options/WITHOUT_FORMAT_EXTENSIONS 1970-01= -01 00:00:00.000000000 +0000 +++ tools/build/options/WITHOUT_FORMAT_EXTENSIONS 2013-02-26 20:35:48.00000= 0000 +0000 @@ -0,0 +1,5 @@ +.\" $FreeBSD$ +Set to not enable +.Fl fformat-extensions +when compiling the kernel. +Also disables all format checking. --/NkBOFFp2J2Af1nK Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iD8DBQFRLVTEXY6L6fI4GtQRAgXVAKDOVf1nUIeCagsdexhrMPnwMsc2wgCgtj6f V3Nnxl+ktDosx3F4fI1N/Rs= =BbUw -----END PGP SIGNATURE----- --/NkBOFFp2J2Af1nK-- From owner-freebsd-arch@FreeBSD.ORG Wed Feb 27 03:05:03 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 0C11A93B; Wed, 27 Feb 2013 03:05:03 +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 DBB733F3; Wed, 27 Feb 2013 03:05:02 +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 CE7AE1A3C35; Tue, 26 Feb 2013 19:04:58 -0800 (PST) Message-ID: <512D77D9.9020205@mu.org> Date: Tue, 26 Feb 2013 19:04:57 -0800 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: Brooks Davis Subject: Re: [RFC] external compiler support References: <20130227003517.GB7348@lor.one-eyed-alien.net> In-Reply-To: <20130227003517.GB7348@lor.one-eyed-alien.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Wed, 27 Feb 2013 03:05:03 -0000 On 2/26/13 4:35 PM, Brooks Davis wrote: > Below (and at http://people.freebsd.org/~brooks/patches/xcc.diff) you > can find an initial patch with proposed commit for external compiler > support. It relies on the existing cross binutils as I'm finding that > the two are fairly separable. With this patch I've been able to build > from amd64 to arm, amd64, and i386 using clang from the lang/clang-devel > port. I've also compiled the tree with a customized clang being > developed at the University of Cambridge. > > The patch is untested with gcc. > > Does this seem like a reasonable approach? I do plan to look at external > binutils support, but it's not on the critical path for our current work > so I've opted to avoid it for now. > > As a bonus for those who don't need an external compiler, but do run > make buildworld frequently, the XCC, XCXX, and XCPP variables can be set > to the location of the installed base system compiler to avoid building > the compiler twice during buildworld. This is very cool work and it's non-invasive. Are there any downsides to bringing it in? (I can't see any). -Alfred > -- Brooks > > ----- > MFP4 222356, 222371, 222375, 222391, 222403, 222407, 222411 > > Add support for an external cross compiler. The cross compiler is > specified by passing the XCC, XCXX, and XCPP variables (corresponding to > CC, CXX, and CPP) to buildworld/buildkernel. The compiler must be clang > or be configured to target the appropriate architecture. > > To speed build times, if XCC is an absolute path or > WITHOUT_CROSS_COMPILER is defined then no cross compiler will be built > during the cross-tools stage. > > To facilitate the use of unmodified external compilers, a > WITHOUT_FORMAT_EXTENSIONS option is available to supress printf format > checking. > > As a short-term measure, supress a few new clang warnings during kernel > builds. > > Sponsored by: DARPA, AFRL > Reviewed by: xxx > > --- ../../freebsd/src/Makefile.inc1 2013-02-26 21:31:09.000000000 +0000 > +++ ./Makefile.inc1 2013-02-26 21:10:50.000000000 +0000 > @@ -280,16 +280,34 @@ > .if ${MK_CDDL} == "no" > WMAKEENV+= NO_CTF=1 > .endif > -.if ${CC:T:Mgcc} == "gcc" > +XCC?= ${CC} > +XCXX?= ${CXX} > +XCPP?= ${CPP} > +.if ${XCC:T:Mgcc} == "gcc" > WMAKE_COMPILER_TYPE= gcc > -.elif ${CC:T:Mclang} == "clang" > +.elif ${XCC:T:Mclang} == "clang" > WMAKE_COMPILER_TYPE= clang > .elif ${MK_CLANG_IS_CC} == "no" > WMAKE_COMPILER_TYPE= gcc > .else > WMAKE_COMPILER_TYPE= clang > .endif > -WMAKEENV+= COMPILER_TYPE=${WMAKE_COMPILER_TYPE} > +.if ${XCC:M/*} > +XFLAGS= --sysroot=${WORLDTMP} -B${WORLDTMP}/usr/bin > +.if ${TARGET_ARCH} != ${MACHINE_ARCH} && ${WMAKE_COMPILER_TYPE} == "clang" > +.if (${TARGET_ARCH} == "arm" || ${TARGET_ARCH} == "armv6") && \ > +${MK_ARM_EABI} != "no" > +TARGET_ABI= gnueabi > +.else > +TARGET_ABI= unknown > +.endif > +TARGET_TRIPLE?= ${TARGET_ARCH:C/amd64/x86_64/}-${TARGET_ABI}-freebsd10.0 > +XFLAGS+= -target ${TARGET_TRIPLE} > +.endif > +.endif > +WMAKEENV+= CC="${XCC} ${XFLAGS}" CXX="${XCXX} ${XFLAGS}" \ > + CPP="${XCPP} ${XFLAGS}" \ > + COMPILER_TYPE=${WMAKE_COMPILER_TYPE} > WMAKE= ${WMAKEENV} ${MAKE} ${WORLD_FLAGS} -f Makefile.inc1 DESTDIR=${WORLDTMP} > > .if ${TARGET_ARCH} == "amd64" || ${TARGET_ARCH} == "powerpc64" > @@ -321,6 +339,7 @@ > > > LIB32FLAGS= -m32 ${LIB32CPUFLAGS} -DCOMPAT_32BIT \ > + --sysroot=${WORLDTMP} \ > -isystem ${LIB32TMP}/usr/include/ \ > -L${LIB32TMP}/usr/lib32 \ > -B${LIB32TMP}/usr/lib32 > @@ -336,8 +355,8 @@ > SHLIBDIR=/usr/lib32 \ > COMPILER_TYPE=${WMAKE_COMPILER_TYPE} > LIB32WMAKEFLAGS+= \ > - CC="${CC} ${LIB32FLAGS}" \ > - CXX="${CXX} ${LIB32FLAGS}" \ > + CC="${XCC} ${LIB32FLAGS}" \ > + CXX="${XCXX} ${LIB32FLAGS}" \ > DESTDIR=${LIB32TMP} \ > -DCOMPAT_32BIT \ > -DLIBRARIES_ONLY \ > @@ -1288,6 +1307,9 @@ > _binutils= gnu/usr.bin/binutils > .endif > > +# If an full path to an external cross compiler is given, don't build > +# a cross compiler. > +.if ${XCC:M/*} == "" && ${MK_CROSS_COMPILER} != "no" > .if ${MK_CLANG} != "no" && (${MK_CLANG_IS_CC} != "no" || ${CC:T:Mclang} == "clang") > _clang= usr.bin/clang > _clang_libs= lib/clang > @@ -1296,6 +1318,7 @@ > .if ${MK_GCC} != "no" && (${MK_CLANG_IS_CC} == "no" || ${TARGET} == "pc98") > _cc= gnu/usr.bin/cc > .endif > +.endif > > cross-tools: > .for _tool in \ > --- ../../freebsd/src/share/mk/bsd.own.mk 2013-02-15 18:49:13.000000000 +0000 > +++ share/mk/bsd.own.mk 2013-02-26 21:10:50.000000000 +0000 > @@ -262,6 +262,7 @@ > CAPSICUM \ > CDDL \ > CPP \ > + CROSS_COMPILER \ > CRYPT \ > CTM \ > CVS \ > @@ -271,6 +272,7 @@ > ED_CRYPTO \ > EXAMPLES \ > FLOPPY \ > + FORMAT_EXTENSIONS \ > FORTH \ > FP_LIBC \ > FREEBSD_UPDATE \ > --- ../../freebsd/src/sys/conf/kern.mk 2012-11-11 22:15:16.000000000 +0000 > +++ sys/conf/kern.mk 2013-02-26 20:35:48.000000000 +0000 > @@ -5,7 +5,7 @@ > # > CWARNFLAGS?= -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes \ > -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual \ > - -Wundef -Wno-pointer-sign -fformat-extensions \ > + -Wundef -Wno-pointer-sign ${FORMAT_EXTENTIONS} \ > -Wmissing-include-dirs -fdiagnostics-show-option \ > ${CWARNEXTRA} > # > @@ -29,7 +29,18 @@ > # enough to error out the whole kernel build. Display them anyway, so there is > # some incentive to fix them eventually. > CWARNEXTRA?= -Wno-error-tautological-compare -Wno-error-empty-body \ > - -Wno-error-parentheses-equality > + -Wno-error-parentheses-equality \ > + -Wno-sizeof-pointer-memaccess \ > + -Wno-unused-command-line-argument \ > + ${NO_WFORMAT} > +.endif > + > +# External compilers may not support our format extensions. Allow them > +# to be disabled. WARNING: format checking is disabled in this case. > +.if ${MK_FORMAT_EXTENSIONS} == "no" > +NO_WFORMAT= -Wno-format > +.else > +FORMAT_EXTENTIONS= -fformat-extensions > .endif > > # > diff -uN ../../freebsd/src/tools/build/options/WITHOUT_CROSS_COMPILER tools/build/options/WITHOUT_CROSS_COMPILER > --- ../../freebsd/src/tools/build/options/WITHOUT_CROSS_COMPILER 1970-01-01 00:00:00.000000000 +0000 > +++ tools/build/options/WITHOUT_CROSS_COMPILER 2013-02-26 21:10:50.000000000 +0000 > @@ -0,0 +1,3 @@ > +.\" $FreeBSD$ > +Set to not build a cross compiler in the cross-tools stage of > +buildworld, buildkernel, etc. > diff -uN ../../freebsd/src/tools/build/options/WITHOUT_FORMAT_EXTENSIONS tools/build/options/WITHOUT_FORMAT_EXTENSIONS > --- ../../freebsd/src/tools/build/options/WITHOUT_FORMAT_EXTENSIONS 1970-01-01 00:00:00.000000000 +0000 > +++ tools/build/options/WITHOUT_FORMAT_EXTENSIONS 2013-02-26 20:35:48.000000000 +0000 > @@ -0,0 +1,5 @@ > +.\" $FreeBSD$ > +Set to not enable > +.Fl fformat-extensions > +when compiling the kernel. > +Also disables all format checking. From owner-freebsd-arch@FreeBSD.ORG Wed Feb 27 11:08:54 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 72E0D946; Wed, 27 Feb 2013 11:08:54 +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 2656F90F; Wed, 27 Feb 2013 11:08:53 +0000 (UTC) Received: from ds4.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id 4E3487D7D; Wed, 27 Feb 2013 11:08:53 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 11C6B9B15; Wed, 27 Feb 2013 12:08:53 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Pawel Jakub Dawidek Subject: Re: Large Capsicum patch for review. References: <20130213025547.GA2025@garage.freebsd.pl> <20130213230221.GB1375@garage.freebsd.pl> <20130223221116.GR1377@garage.freebsd.pl> <5129ADC5.5040306@gmx.de> <512A2CA0.2050509@gmx.de> <20130224235936.GX1377@garage.freebsd.pl> <512B3DBB.4080909@gmx.de> <20130225215004.GA1375@garage.freebsd.pl> <867glvbbjz.fsf@ds4.des.no> <20130226121345.GB1341@garage.freebsd.pl> <86y5eb9sbe.fsf@ds4.des.no> Date: Wed, 27 Feb 2013 12:08:52 +0100 In-Reply-To: <86y5eb9sbe.fsf@ds4.des.no> ("Dag-Erling =?utf-8?Q?Sm=C3=B8rg?= =?utf-8?Q?rav=22's?= message of "Tue, 26 Feb 2013 13:24:05 +0100") Message-ID: <86ppzm814r.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: Christoph Mallon , 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, 27 Feb 2013 11:08:54 -0000 Dag-Erling Sm=C3=B8rgrav writes: > No, but it isn't any *less* CPU-friendly either, so this is not a valid > argument for choosing unsigned int over size_t. (that being said, I usually use unsigned long for iterators, because it feels wrong to use a type named "size" for what is actually an index) DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Wed Feb 27 15:30:09 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 D81FDAD7; Wed, 27 Feb 2013 15:30:09 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) by mx1.freebsd.org (Postfix) with ESMTP id 126789E4; Wed, 27 Feb 2013 15:30:08 +0000 (UTC) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.5/8.14.5) with ESMTP id r1RFUApD017629; Wed, 27 Feb 2013 09:30:10 -0600 (CST) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.5/8.14.5/Submit) id r1RFUA8v017628; Wed, 27 Feb 2013 09:30:10 -0600 (CST) (envelope-from brooks) Date: Wed, 27 Feb 2013 09:30:10 -0600 From: Brooks Davis To: Alfred Perlstein Subject: Re: [RFC] external compiler support Message-ID: <20130227153010.GA17489@lor.one-eyed-alien.net> References: <20130227003517.GB7348@lor.one-eyed-alien.net> <512D77D9.9020205@mu.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FL5UXtIhxfXey3p5" Content-Disposition: inline In-Reply-To: <512D77D9.9020205@mu.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Brooks Davis , 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, 27 Feb 2013 15:30:09 -0000 --FL5UXtIhxfXey3p5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Feb 26, 2013 at 07:04:57PM -0800, Alfred Perlstein wrote: > On 2/26/13 4:35 PM, Brooks Davis wrote: > > Below (and at http://people.freebsd.org/~brooks/patches/xcc.diff) you > > can find an initial patch with proposed commit for external compiler > > support. It relies on the existing cross binutils as I'm finding that > > the two are fairly separable. With this patch I've been able to build > > from amd64 to arm, amd64, and i386 using clang from the lang/clang-devel > > port. I've also compiled the tree with a customized clang being > > developed at the University of Cambridge. > > > > The patch is untested with gcc. > > > > Does this seem like a reasonable approach? I do plan to look at extern= al > > binutils support, but it's not on the critical path for our current work > > so I've opted to avoid it for now. > > > > As a bonus for those who don't need an external compiler, but do run > > make buildworld frequently, the XCC, XCXX, and XCPP variables can be set > > to the location of the installed base system compiler to avoid building > > the compiler twice during buildworld. >=20 > This is very cool work and it's non-invasive. Are there any downsides=20 > to bringing it in? (I can't see any). Other than an increasing pile of code to set up the cross build environment, I don't see a downside. It should be a no-op for most users. -- Brooks --FL5UXtIhxfXey3p5 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iD8DBQFRLiaCXY6L6fI4GtQRAuW+AKCQLKeRr26MpkQOW0dgd27ahFNwPQCgqETH 4QQh7UMEAwCxIgHa50MBCtM= =x4Iu -----END PGP SIGNATURE----- --FL5UXtIhxfXey3p5-- From owner-freebsd-arch@FreeBSD.ORG Wed Feb 27 15:57:18 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 C3C12224 for ; Wed, 27 Feb 2013 15:57:18 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ia0-x232.google.com (mail-ia0-x232.google.com [IPv6:2607:f8b0:4001:c02::232]) by mx1.freebsd.org (Postfix) with ESMTP id 96CBFACF for ; Wed, 27 Feb 2013 15:57:18 +0000 (UTC) Received: by mail-ia0-f178.google.com with SMTP id y26so584655iab.23 for ; Wed, 27 Feb 2013 07:57:18 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=N/wfUDXyb3Z9XdqO5q8O0QVcthSTGnevAz8w+U+0WKU=; b=G1iQNLOj64NgKYsF9zn3l3BRNnTFUgZRPwFpqdQNcEkZ+F8q/ZO3C1P11caEpVzosX A0vE5aHZLwRk1SPAPS0+6VJAxQFs2cgks2v6k3qtEquzfNHsiT9yQrGerjtSipbYPiuE imlvAlVKrPGO9t0zh9gJifOFrIFLgtHYv+X5/z5x02f3EVP5UPcM9XpsNFMkElV2s9RY rbvpHAxNXZMKlKfTIf5fMLGOywoxhOwGtqQBDpmpLOpO5nRebSNwk6u6rEg/wjrziAXd hYu5A1bbVfD+8EhPPGuuUw35pCeKghrmLPY+fSkFGGF5iFMKd1QAdYPpWq9c9JZcdhQ2 B90A== X-Received: by 10.50.190.164 with SMTP id gr4mr1346276igc.19.1361980638151; Wed, 27 Feb 2013 07:57:18 -0800 (PST) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id vb15sm2377474igb.9.2013.02.27.07.57.16 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Feb 2013 07:57:17 -0800 (PST) Sender: Warner Losh Subject: Re: [RFC] external compiler support Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20130227003517.GB7348@lor.one-eyed-alien.net> Date: Wed, 27 Feb 2013 08:57:14 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <28404C12-67F3-44F0-AB28-02B749472873@bsdimp.com> References: <20130227003517.GB7348@lor.one-eyed-alien.net> To: Brooks Davis X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQnhy5HYnRVhVUi+bLeJ3LtX0WhOMC+wvrR+Mle3Wdv11wWDQRY2aGKq6ROupNw2G8trmkU/ 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: Wed, 27 Feb 2013 15:57:18 -0000 On Feb 26, 2013, at 5:35 PM, Brooks Davis wrote: > Below (and at http://people.freebsd.org/~brooks/patches/xcc.diff) you > can find an initial patch with proposed commit for external compiler > support. It relies on the existing cross binutils as I'm finding that > the two are fairly separable. With this patch I've been able to build > from amd64 to arm, amd64, and i386 using clang from the = lang/clang-devel > port. I've also compiled the tree with a customized clang being > developed at the University of Cambridge. Cool! > The patch is untested with gcc. I'd like to see it tested with gcc :) > Does this seem like a reasonable approach? I do plan to look at = external > binutils support, but it's not on the critical path for our current = work > so I've opted to avoid it for now. The patches I posted a few months ago had that as well... > As a bonus for those who don't need an external compiler, but do run > make buildworld frequently, the XCC, XCXX, and XCPP variables can be = set > to the location of the installed base system compiler to avoid = building > the compiler twice during buildworld. I think this will work, but it is kludgy. I had created a = __X=3D which was prepended to ${CC}, et al, in sys.mk. It = was only defined when you set CROSS_COMPILER_PATH (or = EXTERNAL_COMPILER_PATH, I forget) during the cross building stage. It = also had the advantage of making external cross binutils available. Your = patch could fairly easily use this interface instead of having to set 3 = different variables, which will morph to 10 when you add binutil = support. > -- Brooks >=20 > ----- > MFP4 222356, 222371, 222375, 222391, 222403, 222407, 222411 >=20 > Add support for an external cross compiler. The cross compiler is > specified by passing the XCC, XCXX, and XCPP variables (corresponding = to > CC, CXX, and CPP) to buildworld/buildkernel. The compiler must be = clang > or be configured to target the appropriate architecture. >=20 > To speed build times, if XCC is an absolute path or > WITHOUT_CROSS_COMPILER is defined then no cross compiler will be built > during the cross-tools stage. This change is likely good as-is. > To facilitate the use of unmodified external compilers, a > WITHOUT_FORMAT_EXTENSIONS option is available to supress printf format > checking. This one definitely is good as-is. > As a short-term measure, supress a few new clang warnings during = kernel > builds. >=20 > Sponsored by: DARPA, AFRL > Reviewed by: xxx >=20 > --- ../../freebsd/src/Makefile.inc1 2013-02-26 21:31:09.000000000 = +0000 > +++ ./Makefile.inc1 2013-02-26 21:10:50.000000000 +0000 > @@ -280,16 +280,34 @@ > .if ${MK_CDDL} =3D=3D "no" > WMAKEENV+=3D NO_CTF=3D1 > .endif > -.if ${CC:T:Mgcc} =3D=3D "gcc" > +XCC?=3D ${CC} > +XCXX?=3D ${CXX} > +XCPP?=3D ${CPP} I don't like having three different variables to set. I don't think this = will work with gcc, unless we've fixed all the instances in the tree = where we called AS or LD directly. The patches that I had would set = ${CC}, etc based on a CROSS_COMPILER_PATH=3Dxxx variable. I'd rather see = us do that than have this hacky set 3 variables thing. > +.if ${XCC:T:Mgcc} =3D=3D "gcc" > WMAKE_COMPILER_TYPE=3D gcc > -.elif ${CC:T:Mclang} =3D=3D "clang" > +.elif ${XCC:T:Mclang} =3D=3D "clang" > WMAKE_COMPILER_TYPE=3D clang > .elif ${MK_CLANG_IS_CC} =3D=3D "no" > WMAKE_COMPILER_TYPE=3D gcc > .else > WMAKE_COMPILER_TYPE=3D clang > .endif Is there any way to set the WMAKE_COMPILER_TYPE with these patches? XCC = might be something like mips-cavium-cc which won't trigger any of the = above, unless you also have set WITHOUT_CLANG_IS_CC... > -WMAKEENV+=3D COMPILER_TYPE=3D${WMAKE_COMPILER_TYPE} > +.if ${XCC:M/*} > +XFLAGS=3D --sysroot=3D${WORLDTMP} -B${WORLDTMP}/usr/bin > +.if ${TARGET_ARCH} !=3D ${MACHINE_ARCH} && ${WMAKE_COMPILER_TYPE} =3D=3D= "clang" > +.if (${TARGET_ARCH} =3D=3D "arm" || ${TARGET_ARCH} =3D=3D "armv6") && = \ > +${MK_ARM_EABI} !=3D "no" > +TARGET_ABI=3D gnueabi > +.else > +TARGET_ABI=3D unknown > +.endif We need to fix the gnueabi issue with arm. machine_arch should always = be enough to be self-hosting, and while I fixed the armv6 issue, this = has cropped up in its place :(. > +TARGET_TRIPLE?=3D = ${TARGET_ARCH:C/amd64/x86_64/}-${TARGET_ABI}-freebsd10.0 > +XFLAGS+=3D -target ${TARGET_TRIPLE} > +.endif > +.endif > +WMAKEENV+=3D CC=3D"${XCC} ${XFLAGS}" CXX=3D"${XCXX} ${XFLAGS}" \ > + CPP=3D"${XCPP} ${XFLAGS}" \ > + COMPILER_TYPE=3D${WMAKE_COMPILER_TYPE} > WMAKE=3D ${WMAKEENV} ${MAKE} ${WORLD_FLAGS} -f = Makefile.inc1 DESTDIR=3D${WORLDTMP} >=20 > .if ${TARGET_ARCH} =3D=3D "amd64" || ${TARGET_ARCH} =3D=3D "powerpc64" > @@ -321,6 +339,7 @@ >=20 >=20 > LIB32FLAGS=3D -m32 ${LIB32CPUFLAGS} -DCOMPAT_32BIT \ > + --sysroot=3D${WORLDTMP} \ > -isystem ${LIB32TMP}/usr/include/ \ > -L${LIB32TMP}/usr/lib32 \ > -B${LIB32TMP}/usr/lib32 > @@ -336,8 +355,8 @@ > SHLIBDIR=3D/usr/lib32 \ > COMPILER_TYPE=3D${WMAKE_COMPILER_TYPE} > LIB32WMAKEFLAGS+=3D \ > - CC=3D"${CC} ${LIB32FLAGS}" \ > - CXX=3D"${CXX} ${LIB32FLAGS}" \ > + CC=3D"${XCC} ${LIB32FLAGS}" \ > + CXX=3D"${XCXX} ${LIB32FLAGS}" \ > DESTDIR=3D${LIB32TMP} \ > -DCOMPAT_32BIT \ > -DLIBRARIES_ONLY \ > @@ -1288,6 +1307,9 @@ > _binutils=3D gnu/usr.bin/binutils > .endif >=20 > +# If an full path to an external cross compiler is given, don't build > +# a cross compiler. > +.if ${XCC:M/*} =3D=3D "" && ${MK_CROSS_COMPILER} !=3D "no" > .if ${MK_CLANG} !=3D "no" && (${MK_CLANG_IS_CC} !=3D "no" || = ${CC:T:Mclang} =3D=3D "clang") > _clang=3D usr.bin/clang > _clang_libs=3D lib/clang > @@ -1296,6 +1318,7 @@ > .if ${MK_GCC} !=3D "no" && (${MK_CLANG_IS_CC} =3D=3D "no" || ${TARGET} = =3D=3D "pc98") > _cc=3D gnu/usr.bin/cc > .endif > +.endif >=20 > cross-tools: > .for _tool in \ > --- ../../freebsd/src/share/mk/bsd.own.mk 2013-02-15 = 18:49:13.000000000 +0000 > +++ share/mk/bsd.own.mk 2013-02-26 21:10:50.000000000 +0000 > @@ -262,6 +262,7 @@ > CAPSICUM \ > CDDL \ > CPP \ > + CROSS_COMPILER \ > CRYPT \ > CTM \ > CVS \ > @@ -271,6 +272,7 @@ > ED_CRYPTO \ > EXAMPLES \ > FLOPPY \ > + FORMAT_EXTENSIONS \ > FORTH \ > FP_LIBC \ > FREEBSD_UPDATE \ > --- ../../freebsd/src/sys/conf/kern.mk 2012-11-11 = 22:15:16.000000000 +0000 > +++ sys/conf/kern.mk 2013-02-26 20:35:48.000000000 +0000 > @@ -5,7 +5,7 @@ > # > CWARNFLAGS?=3D -Wall -Wredundant-decls -Wnested-externs = -Wstrict-prototypes \ > -Wmissing-prototypes -Wpointer-arith -Winline = -Wcast-qual \ > - -Wundef -Wno-pointer-sign -fformat-extensions \ > + -Wundef -Wno-pointer-sign ${FORMAT_EXTENTIONS} \ > -Wmissing-include-dirs -fdiagnostics-show-option \ > ${CWARNEXTRA} > # > @@ -29,7 +29,18 @@ > # enough to error out the whole kernel build. Display them anyway, so = there is > # some incentive to fix them eventually. > CWARNEXTRA?=3D -Wno-error-tautological-compare = -Wno-error-empty-body \ > - -Wno-error-parentheses-equality > + -Wno-error-parentheses-equality \ > + -Wno-sizeof-pointer-memaccess \ > + -Wno-unused-command-line-argument \ > + ${NO_WFORMAT} > +.endif > + > +# External compilers may not support our format extensions. Allow = them > +# to be disabled. WARNING: format checking is disabled in this case. > +.if ${MK_FORMAT_EXTENSIONS} =3D=3D "no" > +NO_WFORMAT=3D -Wno-format > +.else > +FORMAT_EXTENTIONS=3D -fformat-extensions > .endif >=20 > # > diff -uN ../../freebsd/src/tools/build/options/WITHOUT_CROSS_COMPILER = tools/build/options/WITHOUT_CROSS_COMPILER > --- ../../freebsd/src/tools/build/options/WITHOUT_CROSS_COMPILER = 1970-01-01 00:00:00.000000000 +0000 > +++ tools/build/options/WITHOUT_CROSS_COMPILER 2013-02-26 = 21:10:50.000000000 +0000 > @@ -0,0 +1,3 @@ > +.\" $FreeBSD$ > +Set to not build a cross compiler in the cross-tools stage of > +buildworld, buildkernel, etc. > diff -uN = ../../freebsd/src/tools/build/options/WITHOUT_FORMAT_EXTENSIONS = tools/build/options/WITHOUT_FORMAT_EXTENSIONS > --- ../../freebsd/src/tools/build/options/WITHOUT_FORMAT_EXTENSIONS = 1970-01-01 00:00:00.000000000 +0000 > +++ tools/build/options/WITHOUT_FORMAT_EXTENSIONS 2013-02-26 = 20:35:48.000000000 +0000 > @@ -0,0 +1,5 @@ > +.\" $FreeBSD$ > +Set to not enable > +.Fl fformat-extensions > +when compiling the kernel. > +Also disables all format checking. From owner-freebsd-arch@FreeBSD.ORG Wed Feb 27 16:08:09 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 CE4F7361 for ; Wed, 27 Feb 2013 16:08:09 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ia0-x233.google.com (mail-ia0-x233.google.com [IPv6:2607:f8b0:4001:c02::233]) by mx1.freebsd.org (Postfix) with ESMTP id 801AFB3B for ; Wed, 27 Feb 2013 16:08:09 +0000 (UTC) Received: by mail-ia0-f179.google.com with SMTP id x24so612547iak.10 for ; Wed, 27 Feb 2013 08:08:09 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=ucFNOXA8ZCEWd9G7K0FohkQuyCWfl7MGAKrcWgAE/j0=; b=pxMwBQMn4GD+0ros+JO/WpK1EWf2dDxiZUcoVCqTVX1HVVrxWYCgiBHjxT/8OvMLmP +j0W21xg9vUJ9BJuC/PNtS4txTMz0B+ZB9tSl9Nklr/0zLimYizlwAzd31Ykl0uIKvgY JN1Lye6JSgAkW5C12p8JyDGELWxJErYlzNqEaOt8UZvCtZXuqNYletanNewAgZ/uSyjO CSocps0eRVvSO+b27mCZz32j6/auj1XF3ekcSJPvt+Wzh/iaV+fnj4uThvpQOH0Kad/B f8uNG89VI5VJ7EaRh3X6R7kAoeCXyxvdMH0MtbCOgZOlKk9s5WMvOqaWs/5RPpxMBsBG vQFw== X-Received: by 10.50.212.105 with SMTP id nj9mr7595923igc.17.1361981289004; Wed, 27 Feb 2013 08:08:09 -0800 (PST) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id ih1sm6782839igc.3.2013.02.27.08.08.06 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Feb 2013 08:08:08 -0800 (PST) Sender: Warner Losh Subject: Re: [RFC] external compiler support Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <28404C12-67F3-44F0-AB28-02B749472873@bsdimp.com> Date: Wed, 27 Feb 2013 09:08:05 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <51BB3E17-128A-4989-B272-D8B40D4B854B@bsdimp.com> References: <20130227003517.GB7348@lor.one-eyed-alien.net> <28404C12-67F3-44F0-AB28-02B749472873@bsdimp.com> To: Warner Losh X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQnlqF/5o55plnrBza74PDCQYEN7st/1lpZo+CRtv/yntRy7f06lulin8ZqIyCdaxohdlgVf Cc: Brooks Davis , 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, 27 Feb 2013 16:08:09 -0000 Ooops, forgot to add one item.. On Feb 27, 2013, at 8:57 AM, Warner Losh wrote: >=20 > On Feb 26, 2013, at 5:35 PM, Brooks Davis wrote: >=20 >> Below (and at http://people.freebsd.org/~brooks/patches/xcc.diff) you >> can find an initial patch with proposed commit for external compiler >> support. It relies on the existing cross binutils as I'm finding = that >> the two are fairly separable. With this patch I've been able to = build >> from amd64 to arm, amd64, and i386 using clang from the = lang/clang-devel >> port. I've also compiled the tree with a customized clang being >> developed at the University of Cambridge. >=20 > Cool! >=20 >> The patch is untested with gcc. >=20 > I'd like to see it tested with gcc :) >=20 >> Does this seem like a reasonable approach? I do plan to look at = external >> binutils support, but it's not on the critical path for our current = work >> so I've opted to avoid it for now. >=20 > The patches I posted a few months ago had that as well... >=20 >> As a bonus for those who don't need an external compiler, but do run >> make buildworld frequently, the XCC, XCXX, and XCPP variables can be = set >> to the location of the installed base system compiler to avoid = building >> the compiler twice during buildworld. >=20 > I think this will work, but it is kludgy. I had created a = __X=3D which was prepended to ${CC}, et al, in sys.mk. It = was only defined when you set CROSS_COMPILER_PATH (or = EXTERNAL_COMPILER_PATH, I forget) during the cross building stage. It = also had the advantage of making external cross binutils available. Your = patch could fairly easily use this interface instead of having to set 3 = different variables, which will morph to 10 when you add binutil = support. I've also started looking into using clang --mumble to doing cross = builds too, so I don't have to have 4 compilers configured and laying = around for the different platforms I play with. That isn't reflected in = the port. I also am having trouble finding my full patch, but a partial patch can = be found at http://people.freebsd.org/~imp/simple-ext.diff. A patch that = looks to be contaminated with other patches but that seems to have all = the bits in it is in http://people.freebsd.org/~imp/ext_comp.diff. I've = not tried to apply either of these patches, and they are about 9 months = old at this point. Should be easy enough to merge forward by hand if = patch just doesn't do it. Warner >> -- Brooks >>=20 >> ----- >> MFP4 222356, 222371, 222375, 222391, 222403, 222407, 222411 >>=20 >> Add support for an external cross compiler. The cross compiler is >> specified by passing the XCC, XCXX, and XCPP variables (corresponding = to >> CC, CXX, and CPP) to buildworld/buildkernel. The compiler must be = clang >> or be configured to target the appropriate architecture. >>=20 >> To speed build times, if XCC is an absolute path or >> WITHOUT_CROSS_COMPILER is defined then no cross compiler will be = built >> during the cross-tools stage. >=20 > This change is likely good as-is. >=20 >> To facilitate the use of unmodified external compilers, a >> WITHOUT_FORMAT_EXTENSIONS option is available to supress printf = format >> checking. >=20 > This one definitely is good as-is. >=20 >> As a short-term measure, supress a few new clang warnings during = kernel >> builds. >>=20 >> Sponsored by: DARPA, AFRL >> Reviewed by: xxx >>=20 >> --- ../../freebsd/src/Makefile.inc1 2013-02-26 21:31:09.000000000 = +0000 >> +++ ./Makefile.inc1 2013-02-26 21:10:50.000000000 +0000 >> @@ -280,16 +280,34 @@ >> .if ${MK_CDDL} =3D=3D "no" >> WMAKEENV+=3D NO_CTF=3D1 >> .endif >> -.if ${CC:T:Mgcc} =3D=3D "gcc" >> +XCC?=3D ${CC} >> +XCXX?=3D ${CXX} >> +XCPP?=3D ${CPP} >=20 > I don't like having three different variables to set. I don't think = this will work with gcc, unless we've fixed all the instances in the = tree where we called AS or LD directly. The patches that I had would = set ${CC}, etc based on a CROSS_COMPILER_PATH=3Dxxx variable. I'd rather = see us do that than have this hacky set 3 variables thing. >=20 >> +.if ${XCC:T:Mgcc} =3D=3D "gcc" >> WMAKE_COMPILER_TYPE=3D gcc >> -.elif ${CC:T:Mclang} =3D=3D "clang" >> +.elif ${XCC:T:Mclang} =3D=3D "clang" >> WMAKE_COMPILER_TYPE=3D clang >> .elif ${MK_CLANG_IS_CC} =3D=3D "no" >> WMAKE_COMPILER_TYPE=3D gcc >> .else >> WMAKE_COMPILER_TYPE=3D clang >> .endif >=20 > Is there any way to set the WMAKE_COMPILER_TYPE with these patches? = XCC might be something like mips-cavium-cc which won't trigger any of = the above, unless you also have set WITHOUT_CLANG_IS_CC... >=20 >> -WMAKEENV+=3D COMPILER_TYPE=3D${WMAKE_COMPILER_TYPE} >> +.if ${XCC:M/*} >> +XFLAGS=3D --sysroot=3D${WORLDTMP} -B${WORLDTMP}/usr/bin >> +.if ${TARGET_ARCH} !=3D ${MACHINE_ARCH} && ${WMAKE_COMPILER_TYPE} =3D=3D= "clang" >> +.if (${TARGET_ARCH} =3D=3D "arm" || ${TARGET_ARCH} =3D=3D "armv6") = && \ >> +${MK_ARM_EABI} !=3D "no" >> +TARGET_ABI=3D gnueabi >> +.else >> +TARGET_ABI=3D unknown >> +.endif >=20 > We need to fix the gnueabi issue with arm. machine_arch should always = be enough to be self-hosting, and while I fixed the armv6 issue, this = has cropped up in its place :(. >=20 >> +TARGET_TRIPLE?=3D = ${TARGET_ARCH:C/amd64/x86_64/}-${TARGET_ABI}-freebsd10.0 >> +XFLAGS+=3D -target ${TARGET_TRIPLE} >> +.endif >> +.endif >> +WMAKEENV+=3D CC=3D"${XCC} ${XFLAGS}" CXX=3D"${XCXX} = ${XFLAGS}" \ >> + CPP=3D"${XCPP} ${XFLAGS}" \ >> + COMPILER_TYPE=3D${WMAKE_COMPILER_TYPE} >> WMAKE=3D ${WMAKEENV} ${MAKE} ${WORLD_FLAGS} -f = Makefile.inc1 DESTDIR=3D${WORLDTMP} >>=20 >> .if ${TARGET_ARCH} =3D=3D "amd64" || ${TARGET_ARCH} =3D=3D = "powerpc64" >> @@ -321,6 +339,7 @@ >>=20 >>=20 >> LIB32FLAGS=3D -m32 ${LIB32CPUFLAGS} -DCOMPAT_32BIT \ >> + --sysroot=3D${WORLDTMP} \ >> -isystem ${LIB32TMP}/usr/include/ \ >> -L${LIB32TMP}/usr/lib32 \ >> -B${LIB32TMP}/usr/lib32 >> @@ -336,8 +355,8 @@ >> SHLIBDIR=3D/usr/lib32 \ >> COMPILER_TYPE=3D${WMAKE_COMPILER_TYPE} >> LIB32WMAKEFLAGS+=3D \ >> - CC=3D"${CC} ${LIB32FLAGS}" \ >> - CXX=3D"${CXX} ${LIB32FLAGS}" \ >> + CC=3D"${XCC} ${LIB32FLAGS}" \ >> + CXX=3D"${XCXX} ${LIB32FLAGS}" \ >> DESTDIR=3D${LIB32TMP} \ >> -DCOMPAT_32BIT \ >> -DLIBRARIES_ONLY \ >> @@ -1288,6 +1307,9 @@ >> _binutils=3D gnu/usr.bin/binutils >> .endif >>=20 >> +# If an full path to an external cross compiler is given, don't = build >> +# a cross compiler. >> +.if ${XCC:M/*} =3D=3D "" && ${MK_CROSS_COMPILER} !=3D "no" >> .if ${MK_CLANG} !=3D "no" && (${MK_CLANG_IS_CC} !=3D "no" || = ${CC:T:Mclang} =3D=3D "clang") >> _clang=3D usr.bin/clang >> _clang_libs=3D lib/clang >> @@ -1296,6 +1318,7 @@ >> .if ${MK_GCC} !=3D "no" && (${MK_CLANG_IS_CC} =3D=3D "no" || = ${TARGET} =3D=3D "pc98") >> _cc=3D gnu/usr.bin/cc >> .endif >> +.endif >>=20 >> cross-tools: >> .for _tool in \ >> --- ../../freebsd/src/share/mk/bsd.own.mk 2013-02-15 = 18:49:13.000000000 +0000 >> +++ share/mk/bsd.own.mk 2013-02-26 21:10:50.000000000 +0000 >> @@ -262,6 +262,7 @@ >> CAPSICUM \ >> CDDL \ >> CPP \ >> + CROSS_COMPILER \ >> CRYPT \ >> CTM \ >> CVS \ >> @@ -271,6 +272,7 @@ >> ED_CRYPTO \ >> EXAMPLES \ >> FLOPPY \ >> + FORMAT_EXTENSIONS \ >> FORTH \ >> FP_LIBC \ >> FREEBSD_UPDATE \ >> --- ../../freebsd/src/sys/conf/kern.mk 2012-11-11 = 22:15:16.000000000 +0000 >> +++ sys/conf/kern.mk 2013-02-26 20:35:48.000000000 +0000 >> @@ -5,7 +5,7 @@ >> # >> CWARNFLAGS?=3D -Wall -Wredundant-decls -Wnested-externs = -Wstrict-prototypes \ >> -Wmissing-prototypes -Wpointer-arith -Winline = -Wcast-qual \ >> - -Wundef -Wno-pointer-sign -fformat-extensions \ >> + -Wundef -Wno-pointer-sign ${FORMAT_EXTENTIONS} \ >> -Wmissing-include-dirs -fdiagnostics-show-option \ >> ${CWARNEXTRA} >> # >> @@ -29,7 +29,18 @@ >> # enough to error out the whole kernel build. Display them anyway, = so there is >> # some incentive to fix them eventually. >> CWARNEXTRA?=3D -Wno-error-tautological-compare = -Wno-error-empty-body \ >> - -Wno-error-parentheses-equality >> + -Wno-error-parentheses-equality \ >> + -Wno-sizeof-pointer-memaccess \ >> + -Wno-unused-command-line-argument \ >> + ${NO_WFORMAT} >> +.endif >> + >> +# External compilers may not support our format extensions. Allow = them >> +# to be disabled. WARNING: format checking is disabled in this = case. >> +.if ${MK_FORMAT_EXTENSIONS} =3D=3D "no" >> +NO_WFORMAT=3D -Wno-format >> +.else >> +FORMAT_EXTENTIONS=3D -fformat-extensions >> .endif >>=20 >> # >> diff -uN ../../freebsd/src/tools/build/options/WITHOUT_CROSS_COMPILER = tools/build/options/WITHOUT_CROSS_COMPILER >> --- ../../freebsd/src/tools/build/options/WITHOUT_CROSS_COMPILER = 1970-01-01 00:00:00.000000000 +0000 >> +++ tools/build/options/WITHOUT_CROSS_COMPILER 2013-02-26 = 21:10:50.000000000 +0000 >> @@ -0,0 +1,3 @@ >> +.\" $FreeBSD$ >> +Set to not build a cross compiler in the cross-tools stage of >> +buildworld, buildkernel, etc. >> diff -uN = ../../freebsd/src/tools/build/options/WITHOUT_FORMAT_EXTENSIONS = tools/build/options/WITHOUT_FORMAT_EXTENSIONS >> --- ../../freebsd/src/tools/build/options/WITHOUT_FORMAT_EXTENSIONS = 1970-01-01 00:00:00.000000000 +0000 >> +++ tools/build/options/WITHOUT_FORMAT_EXTENSIONS 2013-02-26 = 20:35:48.000000000 +0000 >> @@ -0,0 +1,5 @@ >> +.\" $FreeBSD$ >> +Set to not enable >> +.Fl fformat-extensions >> +when compiling the kernel. >> +Also disables all format checking. >=20 From owner-freebsd-arch@FreeBSD.ORG Wed Feb 27 16:52:50 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 240261B8; Wed, 27 Feb 2013 16:52:50 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id D51AFE30; Wed, 27 Feb 2013 16:52:49 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r1RGUX6n036865; Wed, 27 Feb 2013 16:30:33 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id pnr7tms3zhmfbv3sv78canyqfs; Wed, 27 Feb 2013 16:30:33 +0000 (UTC) (envelope-from tim@kientzle.com) Subject: Re: [RFC] external compiler support Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: <28404C12-67F3-44F0-AB28-02B749472873@bsdimp.com> Date: Wed, 27 Feb 2013 08:30:32 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130227003517.GB7348@lor.one-eyed-alien.net> <28404C12-67F3-44F0-AB28-02B749472873@bsdimp.com> To: Warner Losh X-Mailer: Apple Mail (2.1283) Cc: Brooks Davis , 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, 27 Feb 2013 16:52:50 -0000 On Feb 27, 2013, at 7:57 AM, Warner Losh wrote: >> +.if ${TARGET_ARCH} !=3D ${MACHINE_ARCH} && ${WMAKE_COMPILER_TYPE} =3D=3D= "clang" >> +.if (${TARGET_ARCH} =3D=3D "arm" || ${TARGET_ARCH} =3D=3D "armv6") = && \ >> +${MK_ARM_EABI} !=3D "no" >> +TARGET_ABI=3D gnueabi >> +.else >> +TARGET_ABI=3D unknown >> +.endif >=20 > We need to fix the gnueabi issue with arm. machine_arch should always = be enough to be self-hosting, and while I fixed the armv6 issue, this = has cropped up in its place :(. Personally, I would like to see us switch to gnueabi entirely and drop the configuration options. Tim From owner-freebsd-arch@FreeBSD.ORG Wed Feb 27 17:00:11 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 E8ECE42E for ; Wed, 27 Feb 2013 17:00:11 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ye0-f182.google.com (mail-ye0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id B00A0EA9 for ; Wed, 27 Feb 2013 17:00:11 +0000 (UTC) Received: by mail-ye0-f182.google.com with SMTP id r9so104051yen.13 for ; Wed, 27 Feb 2013 09:00:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=nu7f041Qa0X2TOZcEeuuMSbFj8aWqQj/lqRGMQ57nt4=; b=UFDcX1bH3Y3MhQraZR5u/rwdaPaO9ZXtRXUch5JPKDtL7b2rHHrZj6986iH6+ahbhu CP3eb3w7bBwrGwR7yxbZGQHF8FxwD+wsPdHR68cdn0Ft7ywrlQesrcS3/oH5jsm88IAM sMU17h9ABJyEVV+nBJ8u26FUA1NoHhxWVTYoXDih9Wfmo7lQzKHykIGCK3TAdGFIVQcF En6hwid9iDECZHYgWTl77ljWqNdI4KffSloBgB8g+g+N0kCniRe5Fc0dxGSFvoDS6FWY aPekGmULYMVdrS77ar7/rvid8rv70MiOV7BNCErTmcuQD53mf9dEfn0t8+4nGXvRy/IA 87yA== X-Received: by 10.236.117.169 with SMTP id j29mr1959482yhh.43.1361984066385; Wed, 27 Feb 2013 08:54:26 -0800 (PST) Received: from monkey-bot.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPS id x8sm8340324yhn.12.2013.02.27.08.54.24 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Feb 2013 08:54:25 -0800 (PST) Sender: Warner Losh Subject: ARM EABI directions Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Wed, 27 Feb 2013 09:54:23 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130227003517.GB7348@lor.one-eyed-alien.net> <28404C12-67F3-44F0-AB28-02B749472873@bsdimp.com> To: Tim Kientzle X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQmHnt7BdgSSaVLDwQh25zXv7AKyBEvzJ4K7WyZlRIyMyfLGsXhvTNibe3ZIA09P+FvQ9Fe+ Cc: Brooks Davis , 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, 27 Feb 2013 17:00:12 -0000 On Feb 27, 2013, at 9:30 AM, Tim Kientzle wrote: >=20 > On Feb 27, 2013, at 7:57 AM, Warner Losh wrote: >=20 >>> +.if ${TARGET_ARCH} !=3D ${MACHINE_ARCH} && ${WMAKE_COMPILER_TYPE} = =3D=3D "clang" >>> +.if (${TARGET_ARCH} =3D=3D "arm" || ${TARGET_ARCH} =3D=3D "armv6") = && \ >>> +${MK_ARM_EABI} !=3D "no" >>> +TARGET_ABI=3D gnueabi >>> +.else >>> +TARGET_ABI=3D unknown >>> +.endif >>=20 >> We need to fix the gnueabi issue with arm. machine_arch should = always be enough to be self-hosting, and while I fixed the armv6 issue, = this has cropped up in its place :(. >=20 > Personally, I would like to see us switch to gnueabi > entirely and drop the configuration options. Me too, but that would mean breaking 9.x binaries on 10.x systems, so = some thought must be exercised here. My preference would be to support building eabi binaries only, but have = a kernel option that would allow execution of oabi binaries. Then again, we are also heading to the soft fp vs vfp issue too... Warner From owner-freebsd-arch@FreeBSD.ORG Wed Feb 27 17:09:19 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 1F67580D; Wed, 27 Feb 2013 17:09:19 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id E5DB1F3D; Wed, 27 Feb 2013 17:09:18 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r1RH9G7l037186; Wed, 27 Feb 2013 17:09:16 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id v6feiyk9zzsubemtd8df3k8cga; Wed, 27 Feb 2013 17:09:16 +0000 (UTC) (envelope-from tim@kientzle.com) Subject: Re: ARM EABI directions Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Tim Kientzle In-Reply-To: Date: Wed, 27 Feb 2013 09:09:15 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <0435EF00-62B4-4389-BB3A-3351FC522C34@kientzle.com> References: <20130227003517.GB7348@lor.one-eyed-alien.net> <28404C12-67F3-44F0-AB28-02B749472873@bsdimp.com> To: Warner Losh X-Mailer: Apple Mail (2.1283) Cc: Brooks Davis , 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, 27 Feb 2013 17:09:19 -0000 >>=20 >>>> +.if ${TARGET_ARCH} !=3D ${MACHINE_ARCH} && ${WMAKE_COMPILER_TYPE} = =3D=3D "clang" >>>> +.if (${TARGET_ARCH} =3D=3D "arm" || ${TARGET_ARCH} =3D=3D "armv6") = && \ >>>> +${MK_ARM_EABI} !=3D "no" >>>> +TARGET_ABI=3D gnueabi >>>> +.else >>>> +TARGET_ABI=3D unknown >>>> +.endif >>>=20 >>> We need to fix the gnueabi issue with arm. machine_arch should = always be enough to be self-hosting, and while I fixed the armv6 issue, = this has cropped up in its place :(. >>=20 >> Personally, I would like to see us switch to gnueabi >> entirely and drop the configuration options. >=20 > Me too, but that would mean breaking 9.x binaries on 10.x systems, so = some thought must be exercised here. Why? ARM was Tier 2 for FreeBSD 9.x, and the FreeBSD package builds still don't support ARM packages, so I'm not convinced that would be a problem. OTOH, I'm hoping we can get ARM to Tier 1 for 10.x, so this will be a concern after that point. > My preference would be to support building eabi binaries only, but = have a kernel option that would allow execution of oabi binaries. That would make sense. ISTR a thread discussing whether it was possible to transparently support both eabi and oabi syscalls. > Then again, we are also heading to the soft fp vs vfp issue too=85 Yeah. Tim From owner-freebsd-arch@FreeBSD.ORG Wed Feb 27 17:53:41 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 48F206FC; Wed, 27 Feb 2013 17:53:41 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by mx1.freebsd.org (Postfix) with ESMTP id D91E721F; Wed, 27 Feb 2013 17:53:40 +0000 (UTC) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKUS5II98Rck2bMVSl1N3z2jsRVqX8FGdT@postini.com; Wed, 27 Feb 2013 09:53:40 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 27 Feb 2013 09:50:10 -0800 Received: from chaos.jnpr.net (chaos.jnpr.net [172.24.29.229]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id r1RHo6340792; Wed, 27 Feb 2013 09:50:08 -0800 (PST) (envelope-from sjg@juniper.net) Received: from chaos.jnpr.net (localhost [127.0.0.1]) by chaos.jnpr.net (Postfix) with ESMTP id A604A58096; Wed, 27 Feb 2013 09:50:06 -0800 (PST) To: Warner Losh Subject: Re: [RFC] external compiler support In-Reply-To: <51BB3E17-128A-4989-B272-D8B40D4B854B@bsdimp.com> References: <20130227003517.GB7348@lor.one-eyed-alien.net> <28404C12-67F3-44F0-AB28-02B749472873@bsdimp.com> <51BB3E17-128A-4989-B272-D8B40D4B854B@bsdimp.com> Comments: In-reply-to: Warner Losh message dated "Wed, 27 Feb 2013 09:08:05 -0700." From: "Simon J. Gerraty" X-Mailer: MH-E 7.82+cvs; nmh 1.3; GNU Emacs 22.3.1 Date: Wed, 27 Feb 2013 09:50:06 -0800 Message-ID: <20130227175006.A604A58096@chaos.jnpr.net> MIME-Version: 1.0 Content-Type: text/plain Cc: freebsd-arch@freebsd.org, Brooks Davis , sjg@juniper.net 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, 27 Feb 2013 17:53:41 -0000 On Wed, 27 Feb 2013 09:08:05 -0700, Warner Losh writes: >> I think this will work, but it is kludgy. I had created a __X= > >I also am having trouble finding my full patch, but a partial patch can be fou I prefer this approach too, but would use a more explicit variable than __X (which I could easily imagine someone thinking they could safely use within their own makefile for some purpose). Eg. we currently have stuff like: CC?= ${BUILD_TOOL_PREFIX}/${CROSS_TARGET_PREFIX}gcc since these aren't variables that anyone needs to manipulate regularly a little verbosity doesn't hurt. Further, having them composed from other bits can also be useful (eg. most dev machines here use nfs mounted toolchains, but others use local toolchains). So (probably taking things too far - I didn't come up with all this ;-) BUILD_TOOL_PREFIX?= ${TOOLCHAIN_PREFIX}/${TOOLCHAIN_${MACHINE}}/bin CROSS_TARGET_PREFIX?= ${CROSS_TARGET}- CROSS_TARGET?= ${CROSS_TARGET_${MACHINE}} and a toolchain.mk sets CROSS_TARGET_* for all the supported machines. Of course as you note: >I've also started looking into using clang --mumble to doing cross builds too, can simplify things (for some value of "--mumble); I managed to get clang to produce i386 apps on amd64, but the "--mumble" wasn't obvious or documented (that I could find) and infact the man page implied other things that don't work. --sjg From owner-freebsd-arch@FreeBSD.ORG Wed Feb 27 18:37:15 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 94D26C20 for ; Wed, 27 Feb 2013 18:37:15 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-gh0-f182.google.com (mail-gh0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5ACEA70D for ; Wed, 27 Feb 2013 18:37:15 +0000 (UTC) Received: by mail-gh0-f182.google.com with SMTP id z15so127959ghb.41 for ; Wed, 27 Feb 2013 10:37:09 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=zXuGAJbizBSYDDwyfZzwnvZG1CZ60+AlUGjfWQOpl+c=; b=JFoVf9f/sMtQU7C+kmLg7nSBG6J8uT/tePoKNjM5Y7NJ2QgvStorgePhJ2ukyy4gyJ 11QYdN4JJIh6NtAhnHyufjizcrjh9onJ0zfezxurftBsPPGO8kCG7YLAkUcv9ZHx4W5f LLxI8JxQAWlsuOeofnCTtGiVt4kuGrpQoBchML4A3gHck4hKy6eFLpAHOwiGRYtu020z KV6zxQls5FpU43MBO68SBy327WFMTajSXY+0gJMpklYHS+osIA3QhyjpceV6XZ09eh4u fx6UtIe1Dh+CeROuaJzgOv/036qW29b2gYLwFrmdwVNPKNxetKk0sCxVRsDoY+PmFkpb adLQ== X-Received: by 10.236.147.35 with SMTP id s23mr2288314yhj.97.1361990229351; Wed, 27 Feb 2013 10:37:09 -0800 (PST) Received: from monkey-bot.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPS id g27sm4737736yhm.21.2013.02.27.10.37.07 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Feb 2013 10:37:08 -0800 (PST) Sender: Warner Losh Subject: Re: [RFC] external compiler support Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20130227175006.A604A58096@chaos.jnpr.net> Date: Wed, 27 Feb 2013 11:37:05 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130227003517.GB7348@lor.one-eyed-alien.net> <28404C12-67F3-44F0-AB28-02B749472873@bsdimp.com> <51BB3E17-128A-4989-B272-D8B40D4B854B@bsdimp.com> <20130227175006.A604A58096@chaos.jnpr.net> To: "Simon J. Gerraty" X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQlkSzOAX+Ii0jXTsv2Xqv8EioGELW6fxQS8HpAXtYa2Rjzo3hFEj2F61VufCIvifzDpggyI Cc: Brooks Davis , 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, 27 Feb 2013 18:37:15 -0000 On Feb 27, 2013, at 10:50 AM, Simon J. Gerraty wrote: >=20 > On Wed, 27 Feb 2013 09:08:05 -0700, Warner Losh writes: >>> I think this will work, but it is kludgy. I had created a = __X=3D >>=20 >> I also am having trouble finding my full patch, but a partial patch = can be fou >=20 > I prefer this approach too, but would use a more explicit variable = than > __X (which I could easily imagine someone thinking they could safely = use > within their own makefile for some purpose). > Eg. we currently have stuff like: >=20 > CC?=3D ${BUILD_TOOL_PREFIX}/${CROSS_TARGET_PREFIX}gcc >=20 > since these aren't variables that anyone needs to manipulate regularly > a little verbosity doesn't hurt. That stray / will kill you :) The __X thing (which I'll grant could be better named, but it is in a = file that needs to be very pure and I don't know if POSIX allows __ = prefix for purely internal things on make or not) was intended to = encompass everything you'd need, whether that is just = /usr/local/arm-freebsd/bin or something more complicated like = /usr/local/bin/arm-linux-gnueabi- whatever. > Further, having them composed from other bits can also be useful > (eg. most dev machines here use nfs mounted toolchains, but others use > local toolchains). >=20 > So (probably taking things too far - I didn't come up with all this = ;-) >=20 > BUILD_TOOL_PREFIX?=3D ${TOOLCHAIN_PREFIX}/${TOOLCHAIN_${MACHINE}}/bin > CROSS_TARGET_PREFIX?=3D ${CROSS_TARGET}- > CROSS_TARGET?=3D ${CROSS_TARGET_${MACHINE}} >=20 > and a toolchain.mk sets CROSS_TARGET_* for all the supported machines. Yea, that likely does take things a bit far. > Of course as you note: >=20 >> I've also started looking into using clang --mumble to doing cross = builds too, >=20 > can simplify things (for some value of "--mumble); I managed to get > clang to produce i386 apps on amd64, but the "--mumble" wasn't obvious > or documented (that I could find) and infact the man page implied = other=20 > things that don't work. Yea, they only half work right now. '-ccc-host-triple arm-none-freebsd = -msoft-float -march armv5' might be a typical --mumble that one would = want to do. It generates the right .s file, but uses the wrong = assembler. Warner= From owner-freebsd-arch@FreeBSD.ORG Wed Feb 27 18:51:59 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 66934380; Wed, 27 Feb 2013 18:51:59 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from smtp4.clear.net.nz (smtp4.clear.net.nz [203.97.37.64]) by mx1.freebsd.org (Postfix) with ESMTP id 3477F7E7; Wed, 27 Feb 2013 18:51:58 +0000 (UTC) Received: from mxin3-orange.clear.net.nz (lb2-srcnat.clear.net.nz [203.97.32.237]) by smtp4.clear.net.nz (CLEAR Net Mail) with ESMTP id <0MIW002WG72FVF40@smtp4.clear.net.nz>; Thu, 28 Feb 2013 07:51:52 +1300 (NZDT) Received: from 202-0-48-19.paradise.net.nz (HELO bender) ([202.0.48.19]) by smtpin32.paradise.net.nz with ESMTP; Thu, 28 Feb 2013 07:51:51 +1300 Date: Thu, 28 Feb 2013 07:51:25 +1300 From: Andrew Turner Subject: Re: ARM EABI directions In-reply-to: <0435EF00-62B4-4389-BB3A-3351FC522C34@kientzle.com> To: Tim Kientzle Message-id: <20130228075125.3e037bc4@bender> MIME-version: 1.0 Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: 8BIT References: <20130227003517.GB7348@lor.one-eyed-alien.net> <28404C12-67F3-44F0-AB28-02B749472873@bsdimp.com> <0435EF00-62B4-4389-BB3A-3351FC522C34@kientzle.com> Cc: Brooks Davis , 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, 27 Feb 2013 18:51:59 -0000 On Wed, 27 Feb 2013 09:09:15 -0800 Tim Kientzle wrote: > >> > >>>> +.if ${TARGET_ARCH} != ${MACHINE_ARCH} && ${WMAKE_COMPILER_TYPE} > >>>> == "clang" +.if (${TARGET_ARCH} == "arm" || ${TARGET_ARCH} == > >>>> "armv6") && \ +${MK_ARM_EABI} != "no" > >>>> +TARGET_ABI= gnueabi > >>>> +.else > >>>> +TARGET_ABI= unknown > >>>> +.endif > >>> > >>> We need to fix the gnueabi issue with arm. machine_arch should > >>> always be enough to be self-hosting, and while I fixed the armv6 > >>> issue, this has cropped up in its place :(. > >> > >> Personally, I would like to see us switch to gnueabi > >> entirely and drop the configuration options. > > > > Me too, but that would mean breaking 9.x binaries on 10.x systems, > > so some thought must be exercised here. It also breaks for people doing native builds. In this case I'm planning on providing a bootstrap tarball. > Why? ARM was Tier 2 for FreeBSD 9.x, and the FreeBSD > package builds still don't support ARM packages, so I'm > not convinced that would be a problem. > > OTOH, I'm hoping we can get ARM to Tier 1 for 10.x, so > this will be a concern after that point. This is why I'm trying to finish of this support and get it tested & enabled by default. > > My preference would be to support building eabi binaries only, but > > have a kernel option that would allow execution of oabi binaries. > > That would make sense. ISTR a thread discussing whether > it was possible to transparently support both eabi and oabi > syscalls. It is possible, I just never finished the code, and am unlikely to as it would hold back other work. > > Then again, we are also heading to the soft fp vs vfp issue too… > > Yeah. While vfp is optional on ARMv6 & v7 almost all SoCs have it, I don't know of any that are missing it. I'm planning on making EABI with Hard-Float the default on armv6. All the armv6 cores we support have some level of VFP support in them. As floating-point values are passed in using the VFP registers the hard-float code will fail on chips without the VFP unit. If someone finds one that is missing it we could add a new TARGET_ARCH to build without vfp. Andrew From owner-freebsd-arch@FreeBSD.ORG Wed Feb 27 19:08:07 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 18020772 for ; Wed, 27 Feb 2013 19:08:07 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) by mx1.freebsd.org (Postfix) with ESMTP id 2F8F3887 for ; Wed, 27 Feb 2013 19:08:04 +0000 (UTC) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.5/8.14.5) with ESMTP id r1RJ8496019055; Wed, 27 Feb 2013 13:08:04 -0600 (CST) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.5/8.14.5/Submit) id r1RJ84F1019054; Wed, 27 Feb 2013 13:08:04 -0600 (CST) (envelope-from brooks) Date: Wed, 27 Feb 2013 13:08:04 -0600 From: Brooks Davis To: Warner Losh Subject: Re: [RFC] external compiler support Message-ID: <20130227190804.GB17489@lor.one-eyed-alien.net> References: <20130227003517.GB7348@lor.one-eyed-alien.net> <28404C12-67F3-44F0-AB28-02B749472873@bsdimp.com> <51BB3E17-128A-4989-B272-D8B40D4B854B@bsdimp.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="aM3YZ0Iwxop3KEKx" Content-Disposition: inline In-Reply-To: <51BB3E17-128A-4989-B272-D8B40D4B854B@bsdimp.com> 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: Wed, 27 Feb 2013 19:08:07 -0000 --aM3YZ0Iwxop3KEKx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 27, 2013 at 09:08:05AM -0700, Warner Losh wrote: > Ooops, forgot to add one item.. >=20 >=20 > On Feb 27, 2013, at 8:57 AM, Warner Losh wrote: >=20 > >=20 > > On Feb 26, 2013, at 5:35 PM, Brooks Davis wrote: > >=20 > >> Below (and at http://people.freebsd.org/~brooks/patches/xcc.diff) you > >> can find an initial patch with proposed commit for external compiler > >> support. It relies on the existing cross binutils as I'm finding that > >> the two are fairly separable. With this patch I've been able to build > >> from amd64 to arm, amd64, and i386 using clang from the lang/clang-dev= el > >> port. I've also compiled the tree with a customized clang being > >> developed at the University of Cambridge. > >=20 > > Cool! > >=20 > >> The patch is untested with gcc. > >=20 > > I'd like to see it tested with gcc :) > >=20 > >> Does this seem like a reasonable approach? I do plan to look at exter= nal > >> binutils support, but it's not on the critical path for our current wo= rk > >> so I've opted to avoid it for now. > >=20 > > The patches I posted a few months ago had that as well... > >=20 > >> As a bonus for those who don't need an external compiler, but do run > >> make buildworld frequently, the XCC, XCXX, and XCPP variables can be s= et > >> to the location of the installed base system compiler to avoid building > >> the compiler twice during buildworld. > >=20 > > I think this will work, but it is kludgy. I had created a __X=3D which was prepended to ${CC}, et al, in sys.mk. It was only defined= when you set CROSS_COMPILER_PATH (or EXTERNAL_COMPILER_PATH, I forget) dur= ing the cross building stage. It also had the advantage of making external = cross binutils available. Your patch could fairly easily use this interface= instead of having to set 3 different variables, which will morph to 10 whe= n you add binutil support. >=20 I think something like this will have to be done for binutils given the way -B works, but I don't think it's workable in the general compiler case because I want to be able to use gcc46 or a future clang33 or similar as CC without changing the system compiler. Ideally I'd also like to support clang's method of finding appropriate binutils by looking first for /binutils/path/${TARGET_TRIPLE}-tool and then /binutils/path/tool. As a strawman, let's say we add a CROSS_COMPILER_PATH and a CROSS_BINUTILS_PATH. The former will set XCC, XCXX, and XCPP if they are unset. The latter will control -B and set the various binutils variables (XNM, XLD, etc). The sys.mk solution seems clean at first glance, but I don't think it's sufficently general. It's also insufficient because you need --sysroot unless you want to build a sysroot somewhere and hardcode paths to it into your toolchain. Worse, if you want rescue to work, --sysroot must be part of CC etc because crunchgen doesn't make it easy to manipulate CFLAGS. > I've also started looking into using clang --mumble to doing cross builds= too, so I don't have to have 4 compilers configured and laying around for = the different platforms I play with. That isn't reflected in the port. >=20 I'm not sure what you mean by "That isn't reflected in the port". -- Brooks --aM3YZ0Iwxop3KEKx Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iD8DBQFRLlmTXY6L6fI4GtQRAofbAKCopj7smMltMQoPyGfIgzdm2pOi5ACeNTl0 Pc/QCuHxdfM+ASNWYl1hTFA= =f5rX -----END PGP SIGNATURE----- --aM3YZ0Iwxop3KEKx-- From owner-freebsd-arch@FreeBSD.ORG Wed Feb 27 19:36:41 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 BDB01FDF; Wed, 27 Feb 2013 19:36:41 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by mx1.freebsd.org (Postfix) with ESMTP id 587329DB; Wed, 27 Feb 2013 19:36:41 +0000 (UTC) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKUS5gQmbTmpzoUocvuDo1apW6F8f2BoH8@postini.com; Wed, 27 Feb 2013 11:36:41 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 27 Feb 2013 11:32:45 -0800 Received: from chaos.jnpr.net (chaos.jnpr.net [172.24.29.229]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id r1RJWi311026; Wed, 27 Feb 2013 11:32:44 -0800 (PST) (envelope-from sjg@juniper.net) Received: from chaos.jnpr.net (localhost [127.0.0.1]) by chaos.jnpr.net (Postfix) with ESMTP id 9330358096; Wed, 27 Feb 2013 11:32:44 -0800 (PST) To: Warner Losh Subject: Re: [RFC] external compiler support In-Reply-To: References: <20130227003517.GB7348@lor.one-eyed-alien.net> <28404C12-67F3-44F0-AB28-02B749472873@bsdimp.com> <51BB3E17-128A-4989-B272-D8B40D4B854B@bsdimp.com> <20130227175006.A604A58096@chaos.jnpr.net> Comments: In-reply-to: Warner Losh message dated "Wed, 27 Feb 2013 11:37:05 -0700." From: "Simon J. Gerraty" X-Mailer: MH-E 7.82+cvs; nmh 1.3; GNU Emacs 22.3.1 Date: Wed, 27 Feb 2013 11:32:44 -0800 Message-ID: <20130227193244.9330358096@chaos.jnpr.net> MIME-Version: 1.0 Content-Type: text/plain Cc: Brooks Davis , 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, 27 Feb 2013 19:36:41 -0000 On Wed, 27 Feb 2013 11:37:05 -0700, Warner Losh writes: >> CC?=3D ${BUILD_TOOL_PREFIX}/${CROSS_TARGET_PREFIX}gcc >>=20 >> since these aren't variables that anyone needs to manipulate regularly >> a little verbosity doesn't hurt. > >That stray / will kill you :) Sure, but we only ever use external toolchains. The setup would of necessity be different in freebsd. My point was a more verbose variable name would be a good idea. Thanks --sjg From owner-freebsd-arch@FreeBSD.ORG Wed Feb 27 19:58:08 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 68631A23 for ; Wed, 27 Feb 2013 19:58:08 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) by mx1.freebsd.org (Postfix) with ESMTP id 12DF5AD7 for ; Wed, 27 Feb 2013 19:58:06 +0000 (UTC) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.5/8.14.5) with ESMTP id r1RJw7sM019371; Wed, 27 Feb 2013 13:58:07 -0600 (CST) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.5/8.14.5/Submit) id r1RJw7vC019370; Wed, 27 Feb 2013 13:58:07 -0600 (CST) (envelope-from brooks) Date: Wed, 27 Feb 2013 13:58:07 -0600 From: Brooks Davis To: "Simon J. Gerraty" Subject: Re: [RFC] external compiler support Message-ID: <20130227195807.GA19255@lor.one-eyed-alien.net> References: <20130227003517.GB7348@lor.one-eyed-alien.net> <28404C12-67F3-44F0-AB28-02B749472873@bsdimp.com> <51BB3E17-128A-4989-B272-D8B40D4B854B@bsdimp.com> <20130227175006.A604A58096@chaos.jnpr.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="sm4nu43k4a2Rpi4c" Content-Disposition: inline In-Reply-To: <20130227175006.A604A58096@chaos.jnpr.net> 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: Wed, 27 Feb 2013 19:58:08 -0000 --sm4nu43k4a2Rpi4c Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 27, 2013 at 09:50:06AM -0800, Simon J. Gerraty wrote: >=20 > On Wed, 27 Feb 2013 09:08:05 -0700, Warner Losh writes: > >> I think this will work, but it is kludgy. I had created a __X=3D > > > >I also am having trouble finding my full patch, but a partial patch can = be fou >=20 > I prefer this approach too, but would use a more explicit variable than > __X (which I could easily imagine someone thinking they could safely use > within their own makefile for some purpose). > Eg. we currently have stuff like: >=20 > CC?=3D ${BUILD_TOOL_PREFIX}/${CROSS_TARGET_PREFIX}gcc >=20 > since these aren't variables that anyone needs to manipulate regularly > a little verbosity doesn't hurt. >=20 > Further, having them composed from other bits can also be useful > (eg. most dev machines here use nfs mounted toolchains, but others use > local toolchains). >=20 > So (probably taking things too far - I didn't come up with all this ;-) >=20 > BUILD_TOOL_PREFIX?=3D ${TOOLCHAIN_PREFIX}/${TOOLCHAIN_${MACHINE}}/bin > CROSS_TARGET_PREFIX?=3D ${CROSS_TARGET}- > CROSS_TARGET?=3D ${CROSS_TARGET_${MACHINE}} >=20 > and a toolchain.mk sets CROSS_TARGET_* for all the supported machines. Adding the equivalent of Warner's ${__X} (however you spell it) doesn't seem to hurt anything, but it doesn't seem to help much either. You quickly end up setting many of the values. I'd be fine with adding something if it seems generally useful, but I don't think I'd use it at all in a buildworld/buildkernel type cross build where I want to control the whole name of the commands without having to hack up a directory of symlinks to the tools I intend to use (in our case, we're only replacing the compiler and want to easily switch between 3-4 non-default versions of clang). > Of course as you note: >=20 > >I've also started looking into using clang --mumble to doing cross build= s too, >=20 > can simplify things (for some value of "--mumble); I managed to get > clang to produce i386 apps on amd64, but the "--mumble" wasn't obvious > or documented (that I could find) and infact the man page implied other= =20 > things that don't work. This appears to work: --sysroot /tree/of/headers/and/libraries -B/path/to/binutils For the whole tree to build it must be part of the value of CC. Otherwise /rescue fails as do several things in /boot. -- Brooks --sm4nu43k4a2Rpi4c Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iD8DBQFRLmVPXY6L6fI4GtQRAiHgAKCcYEX73XaheAjR7KPePfBaab8jSACgq8Bs Bu9jWLKtcdPmNrly2JGkC6M= =its8 -----END PGP SIGNATURE----- --sm4nu43k4a2Rpi4c-- From owner-freebsd-arch@FreeBSD.ORG Wed Feb 27 20:33: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 CEDFEAEF; Wed, 27 Feb 2013 20:33:01 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by mx1.freebsd.org (Postfix) with ESMTP id 86415DA2; Wed, 27 Feb 2013 20:33:01 +0000 (UTC) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKUS5tddOLxS47iTPQHHVa4eX48bzFMTtE@postini.com; Wed, 27 Feb 2013 12:33:01 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 27 Feb 2013 12:28:23 -0800 Received: from chaos.jnpr.net (chaos.jnpr.net [172.24.29.229]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id r1RKSM349648; Wed, 27 Feb 2013 12:28:22 -0800 (PST) (envelope-from sjg@juniper.net) Received: from chaos.jnpr.net (localhost [127.0.0.1]) by chaos.jnpr.net (Postfix) with ESMTP id 8F53B58096; Wed, 27 Feb 2013 12:28:22 -0800 (PST) To: Brooks Davis Subject: Re: [RFC] external compiler support In-Reply-To: <20130227195807.GA19255@lor.one-eyed-alien.net> References: <20130227003517.GB7348@lor.one-eyed-alien.net> <28404C12-67F3-44F0-AB28-02B749472873@bsdimp.com> <51BB3E17-128A-4989-B272-D8B40D4B854B@bsdimp.com> <20130227175006.A604A58096@chaos.jnpr.net> <20130227195807.GA19255@lor.one-eyed-alien.net> Comments: In-reply-to: Brooks Davis message dated "Wed, 27 Feb 2013 13:58:07 -0600." From: "Simon J. Gerraty" X-Mailer: MH-E 7.82+cvs; nmh 1.3; GNU Emacs 22.3.1 Date: Wed, 27 Feb 2013 12:28:22 -0800 Message-ID: <20130227202822.8F53B58096@chaos.jnpr.net> MIME-Version: 1.0 Content-Type: text/plain 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: Wed, 27 Feb 2013 20:33:01 -0000 On Wed, 27 Feb 2013 13:58:07 -0600, Brooks Davis writes: >Adding the equivalent of Warner's ${__X} (however you spell it) doesn't >seem to hurt anything, but it doesn't seem to help much either. You The advantage of Warner's approach is that it can work from anywhere in the tree rather than only from top-level. One of my goals is that I should be able to [cross-]build bin/cat just as easily from src/bin/cat as from top-level. Warner's approach fits better in that regard. There is of course a lot more needed. Being able to add machine and even target specific flags for example. These can be just as easily dealt with in share/mk: # add machine/taget flags in order of least to most specific CFLAGS+= ${CFLAGS.${MACHINE}} \ ${CFLAGS.${.TARGET:T:R}} \ ${CFLAGS.${.TARGET:T}} etc. I also find it handy to have CFLAGS_LAST+= ${CFLAGS_LAST.${MACHINE}} \ ${CFLAGS_LAST.${.TARGET:T:R}} \ ${CFLAGS_LAST.${.TARGET:T}} and add ${CFLAGS_LAST} to CFLAGS after Makefile has been read so for example when you don't have proper sysroot support you can add the equivalent of -I/tree/of/headers/include to the end of the -I list. >This appears to work: > >--sysroot /tree/of/headers/and/libraries -B/path/to/binutils > >For the whole tree to build it must be part of the value of CC. No, they just need to be part of the compiler command line. >Otherwise /rescue fails as do several things in /boot. That would presumably be bugs in the relevant makefiles no? From owner-freebsd-arch@FreeBSD.ORG Wed Feb 27 21:02: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 86D9B3C7 for ; Wed, 27 Feb 2013 21:02:43 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-yh0-x231.google.com (mail-yh0-x231.google.com [IPv6:2607:f8b0:4002:c01::231]) by mx1.freebsd.org (Postfix) with ESMTP id 2ECF5F26 for ; Wed, 27 Feb 2013 21:02:43 +0000 (UTC) Received: by mail-yh0-f49.google.com with SMTP id m1so156688yhg.8 for ; Wed, 27 Feb 2013 13:02:42 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=iKMJUZKzy9wMJpnxi1EWzdqmrjyLPe7xSOt6e6KDR9Q=; b=RdxNULCVnHo1tQGs+DRYlMg+7Nc8q3xscIVKi7ANUTUxrwz/GTegpejUzZ74vcbbGi CshmS/XkZkPEG/lRy7KEwf19BFsgx7wcVI7M1asoj4x+IeKI/XsYosGt6NR0wDLqHJUQ wE7TD5qpbiqRgawhyKOtYXua2VQ3M3Ibj9m1nA8NpVxp+gq2b9AynwGxOwiMEzn4yNAd Hw/fbK4H5p1laB9qjHybEurMpXP04H5QQ9OhL11IiWYhF0RkW8A2qTvZhNR8F7zY9zyg Thm+Uz9VWZ2/VLAL72fvCycnpC7bidEXlbFH8oZncVEXB7D3mNyo1JBMy5/QYo4Il4W7 /8lw== X-Received: by 10.236.155.165 with SMTP id j25mr2752346yhk.177.1361998962720; Wed, 27 Feb 2013 13:02:42 -0800 (PST) Received: from monkey-bot.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPS id x16sm9613389yhj.6.2013.02.27.13.02.40 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Feb 2013 13:02:41 -0800 (PST) Sender: Warner Losh Subject: Re: [RFC] external compiler support Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20130227193244.9330358096@chaos.jnpr.net> Date: Wed, 27 Feb 2013 14:02:40 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130227003517.GB7348@lor.one-eyed-alien.net> <28404C12-67F3-44F0-AB28-02B749472873@bsdimp.com> <51BB3E17-128A-4989-B272-D8B40D4B854B@bsdimp.com> <20130227175006.A604A58096@chaos.jnpr.net> <20130227193244.9330358096@chaos.jnpr.net> To: "Simon J. Gerraty" X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQlv19MxDXqNc/Wsnf4B4Z1ZBB1558X3ftgTMIpcBs1HJW8bvhY1vRQ2BHn1ref2UDwI1y7W Cc: Brooks Davis , 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, 27 Feb 2013 21:02:43 -0000 On Feb 27, 2013, at 12:32 PM, Simon J. Gerraty wrote: >=20 > On Wed, 27 Feb 2013 11:37:05 -0700, Warner Losh writes: >>> CC?=3D3D ${BUILD_TOOL_PREFIX}/${CROSS_TARGET_PREFIX}gcc >>> =3D20 >>> since these aren't variables that anyone needs to manipulate = regularly >>> a little verbosity doesn't hurt. >>=20 >> That stray / will kill you :) >=20 > Sure, but we only ever use external toolchains. > The setup would of necessity be different in freebsd. > My point was a more verbose variable name would be a good idea. I'm cool with that, so long as we put __ in front of the name, which was = my point :) Warner From owner-freebsd-arch@FreeBSD.ORG Wed Feb 27 21:06:42 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 4657D763 for ; Wed, 27 Feb 2013 21:06:42 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-gg0-x22e.google.com (mail-gg0-x22e.google.com [IPv6:2607:f8b0:4002:c02::22e]) by mx1.freebsd.org (Postfix) with ESMTP id E82CBF4D for ; Wed, 27 Feb 2013 21:06:41 +0000 (UTC) Received: by mail-gg0-f174.google.com with SMTP id k5so159452ggd.19 for ; Wed, 27 Feb 2013 13:06:41 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=rfGVNZXMbaLFsq33plymT1RxUqC8jv112kzHfgWt9Xw=; b=VR4P7toRzCIahb9PWVJZ1QzcZnyQHoF5P877RVi6TiOhI3pegFGpp1xuNlUzoIrXq8 twipE9fBdUcKRrvES2h9YIQVhMWvfvxIvJasoWrShqgV19lwOpkXuTiSkXi5hKcEk6wP 7U64/51+aN9Hmz35sIxRR0fylFUe8gOOBsjgX2bTwpUVJIGcAN7bHWtYyRe8Pz6hGsa0 pctj134IyCOsqh2ihBGb5YWq94qMS+a50eSvZJmqVl6r0HAJS9IrZnvY6PniArCH/k3b rbrVsHTQYblWFFMX+xl38pMM3gAf15oWCv4LfVD5ooUMIB5QzPtnIUuTFfma8oickeHE l/mQ== X-Received: by 10.236.127.179 with SMTP id d39mr2800205yhi.20.1361999201495; Wed, 27 Feb 2013 13:06:41 -0800 (PST) Received: from monkey-bot.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPS id s3sm9634087yhm.10.2013.02.27.13.06.38 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Feb 2013 13:06:39 -0800 (PST) Sender: Warner Losh Subject: Re: [RFC] external compiler support Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20130227202822.8F53B58096@chaos.jnpr.net> Date: Wed, 27 Feb 2013 14:06:36 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <09800C62-25DA-4BE4-B87B-8B2F0E1C0AF9@bsdimp.com> References: <20130227003517.GB7348@lor.one-eyed-alien.net> <28404C12-67F3-44F0-AB28-02B749472873@bsdimp.com> <51BB3E17-128A-4989-B272-D8B40D4B854B@bsdimp.com> <20130227175006.A604A58096@chaos.jnpr.net> <20130227195807.GA19255@lor.one-eyed-alien.net> <20130227202822.8F53B58096@chaos.jnpr.net> To: "Simon J. Gerraty" X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQmmQWI89i4shU2qkft0YDQ/9Rylv5w6UuWqoy44j04uYCMDAt0xtSltDN6OSezbP/hGksvf Cc: Brooks Davis , 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, 27 Feb 2013 21:06:42 -0000 On Feb 27, 2013, at 1:28 PM, Simon J. Gerraty wrote: >=20 > On Wed, 27 Feb 2013 13:58:07 -0600, Brooks Davis writes: >> Adding the equivalent of Warner's ${__X} (however you spell it) = doesn't >> seem to hurt anything, but it doesn't seem to help much either. You >=20 > The advantage of Warner's approach is that it can work from anywhere = in > the tree rather than only from top-level. >=20 > One of my goals is that I should be able to [cross-]build bin/cat just > as easily from src/bin/cat as from top-level. > Warner's approach fits better in that regard. >=20 > There is of course a lot more needed. > Being able to add machine and even target specific flags for example. > These can be just as easily dealt with in share/mk: >=20 > # add machine/taget flags in order of least to most specific > CFLAGS+=3D ${CFLAGS.${MACHINE}} \ > ${CFLAGS.${.TARGET:T:R}} \ > ${CFLAGS.${.TARGET:T}} >=20 > etc. I also find it handy to have=20 >=20 > CFLAGS_LAST+=3D ${CFLAGS_LAST.${MACHINE}} \ > ${CFLAGS_LAST.${.TARGET:T:R}} \ > ${CFLAGS_LAST.${.TARGET:T}} >=20 > and add ${CFLAGS_LAST} to CFLAGS after Makefile has been read > so for example when you don't have proper sysroot support you can add > the equivalent of -I/tree/of/headers/include to the end of the -I = list. Yes. We don't really have proper sysroot support in our build tree, or = at least didn't for the longest time, so our build doesn't depend on it. = I'm OK making it depend on it, so long as we have this sort of fallback = for includes and libraries... >> This appears to work: >>=20 >> --sysroot /tree/of/headers/and/libraries -B/path/to/binutils >>=20 >> For the whole tree to build it must be part of the value of CC. >=20 > No, they just need to be part of the compiler command line. Correct. I said in email a second ago I wanted to do CC?=3D"${__X}cc = ${__Y}" but what I really want is a CFLAGS=3D"${__Y}..." instead. Again, = for properly named __X and __Y... >> Otherwise /rescue fails as do several things in /boot. >=20 > That would presumably be bugs in the relevant makefiles no? Yea, since I've build the whole tree with 'make xdev'-built external = tools with at least some version of the stuff I build. There was no = problem with /boot and only minor issues with /rescue which were long = ago fixed. Warner= From owner-freebsd-arch@FreeBSD.ORG Wed Feb 27 21:25:45 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 DF8ADC23 for ; Wed, 27 Feb 2013 21:25:45 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-gh0-f175.google.com (mail-gh0-f175.google.com [209.85.160.175]) by mx1.freebsd.org (Postfix) with ESMTP id 7CD0ED6 for ; Wed, 27 Feb 2013 21:25:45 +0000 (UTC) Received: by mail-gh0-f175.google.com with SMTP id g18so162664ghb.34 for ; Wed, 27 Feb 2013 13:25:39 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=+U0p16u3A3WLGmrr4GsQWL+0PFqAwMVnqhAMb5qnVOM=; b=bVrYkka5K6zTFfrj1MynWKorf1GyRb23yQhzm6wfmHxAgFBwu1n3Evircya4GnWxGS u0AtUnMX2/bWsHFwKjygBaHO5fPy+fU3ISwXZme48mDynNC/U6Va78ep0hHv5OZtWVp/ XupRGnslozMSdERBZ1e7mOb+9WN9O3A7t4J+4sHHosd8bFPeVrJuSXR0AT38PvbkcUag 5I9qV7nEiuybuCT4IiBC5BtGKngRbgkl0jYbj7tlONNkWCcLa4E/AuXctFNJhEZbOokt Pe/WoTAbNSABTHF326iNqylyjxyi+brhkjqPRndSnXm4Ogvrf89pkQhujQ4rxZlOqyxd GIaw== X-Received: by 10.236.114.232 with SMTP id c68mr2658640yhh.194.1361998907198; Wed, 27 Feb 2013 13:01:47 -0800 (PST) Received: from monkey-bot.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPS id x16sm9613389yhj.6.2013.02.27.13.01.44 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Feb 2013 13:01:45 -0800 (PST) Sender: Warner Losh Subject: Re: [RFC] external compiler support Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20130227190804.GB17489@lor.one-eyed-alien.net> Date: Wed, 27 Feb 2013 14:01:42 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <13FB8CB0-9937-4BD8-AE89-0D24494D8663@bsdimp.com> References: <20130227003517.GB7348@lor.one-eyed-alien.net> <28404C12-67F3-44F0-AB28-02B749472873@bsdimp.com> <51BB3E17-128A-4989-B272-D8B40D4B854B@bsdimp.com> <20130227190804.GB17489@lor.one-eyed-alien.net> To: Brooks Davis X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQlGXAkvigM+cttHshtpP+NDdz4LOLGTbIO1eV7a+CUsxe3fnksLdl/mymtxWkwO7f8JNW0z 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: Wed, 27 Feb 2013 21:25:45 -0000 On Feb 27, 2013, at 12:08 PM, Brooks Davis wrote: > On Wed, Feb 27, 2013 at 09:08:05AM -0700, Warner Losh wrote: >> Ooops, forgot to add one item.. >>=20 >>=20 >> On Feb 27, 2013, at 8:57 AM, Warner Losh wrote: >>=20 >>>=20 >>> On Feb 26, 2013, at 5:35 PM, Brooks Davis wrote: >>>=20 >>>> Below (and at http://people.freebsd.org/~brooks/patches/xcc.diff) = you >>>> can find an initial patch with proposed commit for external = compiler >>>> support. It relies on the existing cross binutils as I'm finding = that >>>> the two are fairly separable. With this patch I've been able to = build >>>> from amd64 to arm, amd64, and i386 using clang from the = lang/clang-devel >>>> port. I've also compiled the tree with a customized clang being >>>> developed at the University of Cambridge. >>>=20 >>> Cool! >>>=20 >>>> The patch is untested with gcc. >>>=20 >>> I'd like to see it tested with gcc :) >>>=20 >>>> Does this seem like a reasonable approach? I do plan to look at = external >>>> binutils support, but it's not on the critical path for our current = work >>>> so I've opted to avoid it for now. >>>=20 >>> The patches I posted a few months ago had that as well... >>>=20 >>>> As a bonus for those who don't need an external compiler, but do = run >>>> make buildworld frequently, the XCC, XCXX, and XCPP variables can = be set >>>> to the location of the installed base system compiler to avoid = building >>>> the compiler twice during buildworld. >>>=20 >>> I think this will work, but it is kludgy. I had created a = __X=3D which was prepended to ${CC}, et al, in sys.mk. It = was only defined when you set CROSS_COMPILER_PATH (or = EXTERNAL_COMPILER_PATH, I forget) during the cross building stage. It = also had the advantage of making external cross binutils available. Your = patch could fairly easily use this interface instead of having to set 3 = different variables, which will morph to 10 when you add binutil = support. >>=20 >=20 > I think something like this will have to be done for binutils given = the > way -B works, but I don't think it's workable in the general compiler > case because I want to be able to use gcc46 or a future clang33 or > similar as CC without changing the system compiler. Ideally I'd > also like to support clang's method of finding appropriate binutils > by looking first for /binutils/path/${TARGET_TRIPLE}-tool and then > /binutils/path/tool. I didn't know that clang did this, but that's certainly doable. > As a strawman, let's say we add a CROSS_COMPILER_PATH and a > CROSS_BINUTILS_PATH. The former will set XCC, XCXX, and XCPP if they > are unset. The latter will control -B and set the various binutils > variables (XNM, XLD, etc). I'm not sure I like splitting things like that. It is unnatural. > The sys.mk solution seems clean at first glance, but I don't think = it's > sufficently general. It's also insufficient because you need = --sysroot > unless you want to build a sysroot somewhere and hardcode paths to it > into your toolchain. Worse, if you want rescue to work, --sysroot = must > be part of CC etc because crunchgen doesn't make it easy to manipulate > CFLAGS. Yes, that's a hole in the current system. My stuff works great for = xdev-build toolchains, but less well for generic toolchains because of = the sysroot issue. that's one part of your patch I especially liked. >> I've also started looking into using clang --mumble to doing cross = builds too, so I don't have to have 4 compilers configured and laying = around for the different platforms I play with. That isn't reflected in = the port. >>=20 >=20 > I'm not sure what you mean by "That isn't reflected in the port". s/port/patches/ will help. Basically, I did "CC?=3D${__X}cc" when I = should have done "CC?=3D${__X}cc ${__Y}". Warner From owner-freebsd-arch@FreeBSD.ORG Wed Feb 27 21:39:15 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 4732CF13 for ; Wed, 27 Feb 2013 21:39:15 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by mx1.freebsd.org (Postfix) with ESMTP id 99B22196 for ; Wed, 27 Feb 2013 21:39:14 +0000 (UTC) Received: from mailout-de.gmx.net ([10.1.76.12]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0LrH2g-1UpXE73dYi-0137rB for ; Wed, 27 Feb 2013 22:39:07 +0100 Received: (qmail invoked by alias); 27 Feb 2013 21:39:03 -0000 Received: from p5B131D5E.dip.t-dialin.net (EHLO rotluchs.lokal) [91.19.29.94] by mail.gmx.net (mp012) with SMTP; 27 Feb 2013 22:39:03 +0100 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX19CnYUOguZCtaLGJvO1krcmNOtI7Z4VPamnDrloY/ OjZokv9LOe+Xaj Message-ID: <512E7CDA.2020206@gmx.de> Date: Wed, 27 Feb 2013 22:38:34 +0100 From: Christoph Mallon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130222 Thunderbird/17.0.3 MIME-Version: 1.0 To: Pawel Jakub Dawidek Subject: Re: Large Capsicum patch for review. References: <20130213025547.GA2025@garage.freebsd.pl> <20130213230221.GB1375@garage.freebsd.pl> <20130223221116.GR1377@garage.freebsd.pl> <5129ADC5.5040306@gmx.de> <512A2CA0.2050509@gmx.de> <20130224235936.GX1377@garage.freebsd.pl> <512B3DBB.4080909@gmx.de> <20130225215004.GA1375@garage.freebsd.pl> <867glvbbjz.fsf@ds4.des.no> <20130226121345.GB1341@garage.freebsd.pl> In-Reply-To: <20130226121345.GB1341@garage.freebsd.pl> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= , 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, 27 Feb 2013 21:39:15 -0000 On 26.02.2013 13:13, Pawel Jakub Dawidek wrote: > On Tue, Feb 26, 2013 at 11:43:12AM +0100, Dag-Erling Smørgrav wrote: >> Pawel Jakub Dawidek writes: >>> I use size_t as this is preferred type for size, but I don't need size_t >>> for iterator, because I know the value will never need more than 16 >>> bits, so I use int as a more CPU-friendly type. >> >> Using int as an iterator can lead to warnings about signedness mismatch >> in loop conditions etc., so you should at the very least use unsigned >> int. [...] > > I use 'int' for 'ssize_t' and 'unsigned int' for 'size_t'. > >> [...] Besides, size_t is equal to unsigned long on all platforms, so >> "CPU-friendly" is not a valid argument. > > Is long more CPU-friendly than int? Interestingly, yes: 32 bit ints or uints are stored in the lower half of a 64 bit register on AMD64. All 32 bit operations automatically zero extend their result to 64 bits, i.e. the upper half is set to 0. Comparing an uint with size_t can therefore done directly with a 64 bit comparison. But to compare an int with an ssize_t, the int value has to be sign extended to 64 bits. This takes another instruction (movsx) and an extra register to temporarily hold the sign-extended value. On MIPS it's the other way round: 32 bit operations sign extend their result to 64 bits. So comparing int and ssize_t can be done directly and uint+size_t costs another instruction. In summary, mismatched types make the code harder to read and have the potential to force the compiler to produce worse code. Christoph From owner-freebsd-arch@FreeBSD.ORG Wed Feb 27 21:44:46 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 EF14B290 for ; Wed, 27 Feb 2013 21:44:46 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) by mx1.freebsd.org (Postfix) with ESMTP id 39ADE223 for ; Wed, 27 Feb 2013 21:44:46 +0000 (UTC) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.5/8.14.5) with ESMTP id r1RLijDL020029; Wed, 27 Feb 2013 15:44:45 -0600 (CST) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.5/8.14.5/Submit) id r1RLij5F020028; Wed, 27 Feb 2013 15:44:45 -0600 (CST) (envelope-from brooks) Date: Wed, 27 Feb 2013 15:44:45 -0600 From: Brooks Davis To: Warner Losh Subject: Re: [RFC] external compiler support Message-ID: <20130227214445.GA19594@lor.one-eyed-alien.net> References: <20130227003517.GB7348@lor.one-eyed-alien.net> <28404C12-67F3-44F0-AB28-02B749472873@bsdimp.com> <51BB3E17-128A-4989-B272-D8B40D4B854B@bsdimp.com> <20130227190804.GB17489@lor.one-eyed-alien.net> <13FB8CB0-9937-4BD8-AE89-0D24494D8663@bsdimp.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="opJtzjQTFsWo+cga" Content-Disposition: inline In-Reply-To: <13FB8CB0-9937-4BD8-AE89-0D24494D8663@bsdimp.com> 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: Wed, 27 Feb 2013 21:44:47 -0000 --opJtzjQTFsWo+cga Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 27, 2013 at 02:01:42PM -0700, Warner Losh wrote: >=20 > On Feb 27, 2013, at 12:08 PM, Brooks Davis wrote: >=20 > > On Wed, Feb 27, 2013 at 09:08:05AM -0700, Warner Losh wrote: > >> Ooops, forgot to add one item.. > >>=20 > >>=20 > >> On Feb 27, 2013, at 8:57 AM, Warner Losh wrote: > >>=20 > >>>=20 > >>> On Feb 26, 2013, at 5:35 PM, Brooks Davis wrote: > >>>=20 > >>>> Below (and at http://people.freebsd.org/~brooks/patches/xcc.diff) you > >>>> can find an initial patch with proposed commit for external compiler > >>>> support. It relies on the existing cross binutils as I'm finding th= at > >>>> the two are fairly separable. With this patch I've been able to bui= ld > >>>> from amd64 to arm, amd64, and i386 using clang from the lang/clang-d= evel > >>>> port. I've also compiled the tree with a customized clang being > >>>> developed at the University of Cambridge. > >>>=20 > >>> Cool! > >>>=20 > >>>> The patch is untested with gcc. > >>>=20 > >>> I'd like to see it tested with gcc :) > >>>=20 > >>>> Does this seem like a reasonable approach? I do plan to look at ext= ernal > >>>> binutils support, but it's not on the critical path for our current = work > >>>> so I've opted to avoid it for now. > >>>=20 > >>> The patches I posted a few months ago had that as well... > >>>=20 > >>>> As a bonus for those who don't need an external compiler, but do run > >>>> make buildworld frequently, the XCC, XCXX, and XCPP variables can be= set > >>>> to the location of the installed base system compiler to avoid build= ing > >>>> the compiler twice during buildworld. > >>>=20 > >>> I think this will work, but it is kludgy. I had created a __X=3D which was prepended to ${CC}, et al, in sys.mk. It was only defin= ed when you set CROSS_COMPILER_PATH (or EXTERNAL_COMPILER_PATH, I forget) d= uring the cross building stage. It also had the advantage of making externa= l cross binutils available. Your patch could fairly easily use this interfa= ce instead of having to set 3 different variables, which will morph to 10 w= hen you add binutil support. > >>=20 > >=20 > > I think something like this will have to be done for binutils given the > > way -B works, but I don't think it's workable in the general compiler > > case because I want to be able to use gcc46 or a future clang33 or > > similar as CC without changing the system compiler. Ideally I'd > > also like to support clang's method of finding appropriate binutils > > by looking first for /binutils/path/${TARGET_TRIPLE}-tool and then > > /binutils/path/tool. >=20 > I didn't know that clang did this, but that's certainly doable. The key is that for it to work we need to set each tool's name individually. > > As a strawman, let's say we add a CROSS_COMPILER_PATH and a > > CROSS_BINUTILS_PATH. The former will set XCC, XCXX, and XCPP if they > > are unset. The latter will control -B and set the various binutils > > variables (XNM, XLD, etc). >=20 > I'm not sure I like splitting things like that. It is unnatural. That's the traditional view with lots of historic merit. At least in the short term it's not a useful view for me. I want to be able to use our existing infrastructure to build a cross binutils and then use it with an external compiler. In a clang world, we currently have one compiler and many binutils unless we gratuitously build many compilers as the FreeBSD build system currently does. Some day we will likely have an all-llvm toolchain available and then we will have one toolchain for all supported architectures. I suppose could hack what I want to do into the traditional single toolchain world view by build a mips64 xdev toolchain and then building a linkfarm and/or set of wrapper scripts to it and the clang I want to include, but that seems problematic from a reproducability perspective (not to mention performance if I need wrappers to set -B). Having a CROSS_TOOLCHAIN_PATH path that sets both would probably be a useful compromise in this regard. -- Brooks --opJtzjQTFsWo+cga Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iD8DBQFRLn5MXY6L6fI4GtQRAuMtAJ47zXiVZtsVnO1YsKGLjzCwVsnQuQCgi7eG 8XEnYLhtJ3UYYyE5yfW5wfI= =onj4 -----END PGP SIGNATURE----- --opJtzjQTFsWo+cga-- From owner-freebsd-arch@FreeBSD.ORG Wed Feb 27 21:48: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 7E81E3DB for ; Wed, 27 Feb 2013 21:48:05 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-gh0-f175.google.com (mail-gh0-f175.google.com [209.85.160.175]) by mx1.freebsd.org (Postfix) with ESMTP id 0D6B9253 for ; Wed, 27 Feb 2013 21:48:04 +0000 (UTC) Received: by mail-gh0-f175.google.com with SMTP id g18so167087ghb.34 for ; Wed, 27 Feb 2013 13:48:04 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=dM2oANj8yh4iHtFVqoxACVprYNaX+Jwaumg6xQxXueI=; b=iVWRElImv4130R3CQmQnQ+9jhLtCrd1N9l9bu6JH3dTX2ladzdJNdIRhqVtpv9lEb0 LEJq4nJglksAbrThTZfNByuZq06ij2dE3diAlZ5rQzXNUA/QUcdZfBp++ipHBVDcwBp/ vBSvRG1gK/OX+aQONz2dtu6ayVbY+64QoX2djO+bpMu3DXkbv7KOfIYfWr5/sHrbFRe7 xUEo5STq5I09y8H3FLf+C2sOrQBZ0kT7TRUUSuMBWFJwN/ixtYu1K1Csnk1IqPoGMKyl OkUUGnhU1imcK3QH1o33rMDmUVZtF45WiPl6f1nhulGgpu8L53GqyAnkRKv4RorqLVwi 6tdg== X-Received: by 10.236.179.37 with SMTP id g25mr2959289yhm.47.1362001684483; Wed, 27 Feb 2013 13:48:04 -0800 (PST) Received: from monkey-bot.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPS id b62sm9856449yhf.13.2013.02.27.13.48.02 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Feb 2013 13:48:03 -0800 (PST) Sender: Warner Losh Subject: Re: [RFC] external compiler support Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20130227214445.GA19594@lor.one-eyed-alien.net> Date: Wed, 27 Feb 2013 14:47:59 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1CC1DB5A-E87A-456C-AD2C-E203146BB736@bsdimp.com> References: <20130227003517.GB7348@lor.one-eyed-alien.net> <28404C12-67F3-44F0-AB28-02B749472873@bsdimp.com> <51BB3E17-128A-4989-B272-D8B40D4B854B@bsdimp.com> <20130227190804.GB17489@lor.one-eyed-alien.net> <13FB8CB0-9937-4BD8-AE89-0D24494D8663@bsdimp.com> <20130227214445.GA19594@lor.one-eyed-alien.net> To: Brooks Davis X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQmQbnLwIja/1Nqq2DNUlyTiDHXi2U0VfQehMdYokiok636f92H2gO72OdxztXZ8YBGHoBT0 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: Wed, 27 Feb 2013 21:48:05 -0000 On Feb 27, 2013, at 2:44 PM, Brooks Davis wrote: > On Wed, Feb 27, 2013 at 02:01:42PM -0700, Warner Losh wrote: >>=20 >> On Feb 27, 2013, at 12:08 PM, Brooks Davis wrote: >>=20 >>> On Wed, Feb 27, 2013 at 09:08:05AM -0700, Warner Losh wrote: >>>> Ooops, forgot to add one item.. >>>>=20 >>>>=20 >>>> On Feb 27, 2013, at 8:57 AM, Warner Losh wrote: >>>>=20 >>>>>=20 >>>>> On Feb 26, 2013, at 5:35 PM, Brooks Davis wrote: >>>>>=20 >>>>>> Below (and at http://people.freebsd.org/~brooks/patches/xcc.diff) = you >>>>>> can find an initial patch with proposed commit for external = compiler >>>>>> support. It relies on the existing cross binutils as I'm finding = that >>>>>> the two are fairly separable. With this patch I've been able to = build >>>>>> from amd64 to arm, amd64, and i386 using clang from the = lang/clang-devel >>>>>> port. I've also compiled the tree with a customized clang being >>>>>> developed at the University of Cambridge. >>>>>=20 >>>>> Cool! >>>>>=20 >>>>>> The patch is untested with gcc. >>>>>=20 >>>>> I'd like to see it tested with gcc :) >>>>>=20 >>>>>> Does this seem like a reasonable approach? I do plan to look at = external >>>>>> binutils support, but it's not on the critical path for our = current work >>>>>> so I've opted to avoid it for now. >>>>>=20 >>>>> The patches I posted a few months ago had that as well... >>>>>=20 >>>>>> As a bonus for those who don't need an external compiler, but do = run >>>>>> make buildworld frequently, the XCC, XCXX, and XCPP variables can = be set >>>>>> to the location of the installed base system compiler to avoid = building >>>>>> the compiler twice during buildworld. >>>>>=20 >>>>> I think this will work, but it is kludgy. I had created a = __X=3D which was prepended to ${CC}, et al, in sys.mk. It = was only defined when you set CROSS_COMPILER_PATH (or = EXTERNAL_COMPILER_PATH, I forget) during the cross building stage. It = also had the advantage of making external cross binutils available. Your = patch could fairly easily use this interface instead of having to set 3 = different variables, which will morph to 10 when you add binutil = support. >>>>=20 >>>=20 >>> I think something like this will have to be done for binutils given = the >>> way -B works, but I don't think it's workable in the general = compiler >>> case because I want to be able to use gcc46 or a future clang33 or >>> similar as CC without changing the system compiler. Ideally I'd >>> also like to support clang's method of finding appropriate binutils >>> by looking first for /binutils/path/${TARGET_TRIPLE}-tool and then >>> /binutils/path/tool. >>=20 >> I didn't know that clang did this, but that's certainly doable. >=20 > The key is that for it to work we need to set each tool's name > individually. >=20 >>> As a strawman, let's say we add a CROSS_COMPILER_PATH and a >>> CROSS_BINUTILS_PATH. The former will set XCC, XCXX, and XCPP if = they >>> are unset. The latter will control -B and set the various binutils >>> variables (XNM, XLD, etc). >>=20 >> I'm not sure I like splitting things like that. It is unnatural. >=20 > That's the traditional view with lots of historic merit. At least in > the short term it's not a useful view for me. I want to be able to > use our existing infrastructure to build a cross binutils and then use > it with an external compiler. In a clang world, we currently have one > compiler and many binutils unless we gratuitously build many compilers > as the FreeBSD build system currently does. Some day we will likely = have > an all-llvm toolchain available and then we will have one toolchain = for > all supported architectures. >=20 > I suppose could hack what I want to do into the traditional single > toolchain world view by build a mips64 xdev toolchain and then = building > a linkfarm and/or set of wrapper scripts to it and the clang I want to > include, but that seems problematic from a reproducability perspective > (not to mention performance if I need wrappers to set -B). >=20 > Having a CROSS_TOOLCHAIN_PATH path that sets both would probably be a > useful compromise in this regard. Are you suggesting something like: CROSS_COMPILER_PATH?=3D${CROSS_TOOLCHAIN_PATH} CROSS_BINUTILS_PATH?=3D${CROSS_TOOLCHAIN_PATH} If so, I'd agree, that would be a very useful compromise: hits my ease = of use issues, and lets you do what you need on the theory that others = will likely need it too. Warner= From owner-freebsd-arch@FreeBSD.ORG Wed Feb 27 22:05: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 43E77B40; Wed, 27 Feb 2013 22:05:22 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) by mx1.freebsd.org (Postfix) with ESMTP id 89C41386; Wed, 27 Feb 2013 22:05:20 +0000 (UTC) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.5/8.14.5) with ESMTP id r1RM5KKK020164; Wed, 27 Feb 2013 16:05:20 -0600 (CST) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.5/8.14.5/Submit) id r1RM5Kax020163; Wed, 27 Feb 2013 16:05:20 -0600 (CST) (envelope-from brooks) Date: Wed, 27 Feb 2013 16:05:20 -0600 From: Brooks Davis To: "Simon J. Gerraty" Subject: Re: [RFC] external compiler support Message-ID: <20130227220520.GB19594@lor.one-eyed-alien.net> References: <20130227003517.GB7348@lor.one-eyed-alien.net> <28404C12-67F3-44F0-AB28-02B749472873@bsdimp.com> <51BB3E17-128A-4989-B272-D8B40D4B854B@bsdimp.com> <20130227175006.A604A58096@chaos.jnpr.net> <20130227195807.GA19255@lor.one-eyed-alien.net> <20130227202822.8F53B58096@chaos.jnpr.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="eJnRUKwClWJh1Khz" Content-Disposition: inline In-Reply-To: <20130227202822.8F53B58096@chaos.jnpr.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Brooks Davis , 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, 27 Feb 2013 22:05:22 -0000 --eJnRUKwClWJh1Khz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 27, 2013 at 12:28:22PM -0800, Simon J. Gerraty wrote: >=20 > On Wed, 27 Feb 2013 13:58:07 -0600, Brooks Davis writes: > >Adding the equivalent of Warner's ${__X} (however you spell it) doesn't > >seem to hurt anything, but it doesn't seem to help much either. You >=20 > The advantage of Warner's approach is that it can work from anywhere in > the tree rather than only from top-level. >=20 > One of my goals is that I should be able to [cross-]build bin/cat just > as easily from src/bin/cat as from top-level. > Warner's approach fits better in that regard. >=20 > There is of course a lot more needed. > Being able to add machine and even target specific flags for example. > These can be just as easily dealt with in share/mk: >=20 > # add machine/taget flags in order of least to most specific > CFLAGS+=3D ${CFLAGS.${MACHINE}} \ > ${CFLAGS.${.TARGET:T:R}} \ > ${CFLAGS.${.TARGET:T}} >=20 > etc. I also find it handy to have=20 >=20 > CFLAGS_LAST+=3D ${CFLAGS_LAST.${MACHINE}} \ > ${CFLAGS_LAST.${.TARGET:T:R}} \ > ${CFLAGS_LAST.${.TARGET:T}} >=20 > and add ${CFLAGS_LAST} to CFLAGS after Makefile has been read > so for example when you don't have proper sysroot support you can add > the equivalent of -I/tree/of/headers/include to the end of the -I list. I like the end goal, but it doesn't feel like taking this route gets me any less code in Makefile.inc1 in the short term. I don't like that for now it forces me to use traditional names for all these tools (they must match the name of the native tools) and to install them next to each other (or create a link farm to do that). This seems to make it unnecessarily difficult to perform any kind of casual compiler testing across the whole tree. > >This appears to work: > > > >--sysroot /tree/of/headers/and/libraries -B/path/to/binutils > > > >For the whole tree to build it must be part of the value of CC. >=20 > No, they just need to be part of the compiler command line. >=20 > >Otherwise /rescue fails as do several things in /boot. >=20 > That would presumably be bugs in the relevant makefiles no? The problem in both cases is that they need tight control of C(XX)FLAGS in order to generate small or static binaries. There are any number of ways to work around this, but nothing seems very clean. One could introduce yet another ???FLAGS variable that they use explicitly as part of their CFLAGS. Alternatively, one could change them to aggressively filter CFLAGS rather than replacing it. Making the options part of CC works today and avoids needing to modify many makefiles whose products I can't test easily or in many cases at all. Notionally I feel it's equivalent to creating a wrapper script around each tool to change a couple defaults without the overhead or hassle. While I could test the /rescue case, fixing it involves modifying cruchgen and my first attempt to look at it lead me to run away quickly. :) -- Brooks --eJnRUKwClWJh1Khz Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iD8DBQFRLoMfXY6L6fI4GtQRAubYAJ9njJlVIBCj69Eu9Zuu4SP859lxLgCgpB5m WkQnh6rUwnl0vubQrtAeS7A= =eObX -----END PGP SIGNATURE----- --eJnRUKwClWJh1Khz-- From owner-freebsd-arch@FreeBSD.ORG Wed Feb 27 22:15:44 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 82309248 for ; Wed, 27 Feb 2013 22:15:44 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by mx1.freebsd.org (Postfix) with ESMTP id 2D96667F for ; Wed, 27 Feb 2013 22:15:44 +0000 (UTC) Received: from mailout-de.gmx.net ([10.1.76.29]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0LxrcA-1Uw6MS10b6-015Mov for ; Wed, 27 Feb 2013 23:15:40 +0100 Received: (qmail invoked by alias); 27 Feb 2013 22:15:35 -0000 Received: from p5B131D5E.dip.t-dialin.net (EHLO rotluchs.lokal) [91.19.29.94] by mail.gmx.net (mp029) with SMTP; 27 Feb 2013 23:15:35 +0100 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX1/iyYYuUrTi6S5/Iktu5kHPNmzXXm7buXYf9dJHdd canX8vZB+KxzUr Message-ID: <512E8572.6050107@gmx.de> Date: Wed, 27 Feb 2013 23:15:14 +0100 From: Christoph Mallon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130222 Thunderbird/17.0.3 MIME-Version: 1.0 To: Pawel Jakub Dawidek Subject: Re: Large Capsicum patch for review. References: <20130213025547.GA2025@garage.freebsd.pl> <20130213230221.GB1375@garage.freebsd.pl> <20130223221116.GR1377@garage.freebsd.pl> <5129ADC5.5040306@gmx.de> <512A2CA0.2050509@gmx.de> <20130224235936.GX1377@garage.freebsd.pl> <512B3DBB.4080909@gmx.de> <20130225215004.GA1375@garage.freebsd.pl> In-Reply-To: <20130225215004.GA1375@garage.freebsd.pl> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 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: Wed, 27 Feb 2013 22:15:44 -0000 On 25.02.2013 22:50, Pawel Jakub Dawidek wrote: > On Mon, Feb 25, 2013 at 11:32:27AM +0100, Christoph Mallon wrote: >> On 25.02.2013 00:59, Pawel Jakub Dawidek wrote: >>> On Sun, Feb 24, 2013 at 04:07:12PM +0100, Christoph Mallon wrote: >>>> On 24.02.2013 07:05, Christoph Mallon wrote: >>>> - Why did you choose INT_MAX to represent "all capabilities"? >>>> The data type used is ssize_t, so SSIZE_MAX seems more logical. >>>> Further, there are several places where size_t and ssize_t come into contact, which need careful tests and casts to get right. >>>> Maybe it is better to always use size_t and represent "all capabilities" with SIZE_T_MAX or (size_t)-1 (which is guaranteed by C to be the maximal value). >>> >>> This is not used for capabilities, but for white-listing ioctl commands. >>> INT_MAX seems to just be least odd. We only allow for 256 anyway. >>> I could provide some dedicated define for it, eg. >>> >>> #define CAP_IOCTLS_ALL >> >> A nice name is a good step. >> Still, I would prefer, if consistently only one type (size_t) would be used instead of two/three (ssize_t, size_t and int for the constant). > > Using three types here is not inconsistent, it is a common practise. Using three different types for the same context /is/ inconsistent. > Check out even read(2) and write(2) - they take size as size_t, as there > is no need for a negative size, but they return ssize_t, because they > can return -1 if an error occured. This is exactly what I do in > cap_ioctls_get(). "Common practise" does not automatically turn something into a good idea. > I use size_t as this is preferred type for size, but I don't need size_t > for iterator, because I know the value will never need more than 16 > bits, so I use int as a more CPU-friendly type. See my earlier mail about this. >>>> - I could not verify many changes, e.g. changed requested permissions, because this is just a big diff with no information about the intention of the changes. >>>> A series of smaller diffs with commit logs to state their intent would be really useful for reviewing. >>> >>> The entire history is in perforce, but there are many commits in there. >> >> So effectively the history is lost. > > The entire history is there, nothing is lost: > > http://p4db.freebsd.org/ So effectively it is lost. FreeBSD's history is recorded in its SVN respository. Throwing big patch bombs into it only makes it harder to comprehend changes. >>> The key goals of the patch are: >>> >>> - Move from special capability descriptors that were used to keep >>> capability rights in the file structure to ability to configure >>> capability rights on any descriptor type. >>> >>> - Make capability rights more practical. >>> >>> - Allow for ioctl(2) in capability mode by providing a way to limit >>> permitted ioctl commands. >>> >>> - Allow for limiting permitted fcntl(2) commands. >> >> In a branch in svn one could reread these steps on every commit. >> Or even better, use git(-svn), which can automatically create a nice patch series (like the one I provided). > > Your changes were pretty simple, so they look nice as separate commits. It's the other way round: The changes are simple, because they are separate commits, which do a single thing each. So it is clear what to look for in each commit. > The patch you review is a result of ~2 months of work and exporting > every single change would not create such nice output. If those changes > were implemented totally separated, I could generate several independent > patches, but those changes were implemented together and trying to > separate them now would be, if possible, very time consuming. So > eventhough I agree it would be easier to review them separately, I only > have this single patch. I understand, p4 does not provide a suitable basis for code review. As we have investigated before, it is even necessary to massage its output to make it usable with common tools at all. >>>> --- a/sys/kern/sys_capability.c >>>> +++ b/sys/kern/sys_capability.c >>>> @@ -314,12 +314,12 @@ cap_ioctl_limit_check(struct filedesc *fdp, int fd, const u_long *cmds, >>>> >>>> ocmds = fdp->fd_ofiles[fd].fde_ioctls; >>>> for (i = 0; i < ncmds; i++) { >>>> - for (j = 0; j < oncmds; j++) { >>>> + for (j = 0;; j++) { >>>> + if (j == oncmds) >>>> + return (ENOTCAPABLE); >>>> if (cmds[i] == ocmds[j]) >>>> break; >>>> } >>>> - if (j == oncmds) >>>> - return (ENOTCAPABLE); >>>> } >>>> >>>> return (0); >>> >>> I decided to skip this one. My version is more readable, IMHO, as it is >>> used for other cases like TAILQ_FOREACH(), etc. where the check is >>> already done by the macro. >> >> The duplicate tests do not even match! >> You have to carefully read the code to verify, that if indeed only triggers, when the for loop terminated without break. >> Code duplication is almost always bad, especially if the duplicated code does not fully match. > > I don't agree, sorry. Your loop looks like endless loop at first. If the > loop would be more complex, it would be hard to tell at first glance if > the loop even terminates. For me it looks awkward - there is a place in > 'for ()' for a check, which defines when the loop should end; IMHO it is > there for a reason. The construction I use is widely used, at least in > FreeBSD code and looks obvious to me. At least make the duplicate checks match: == and < are not complements. >>> Applied, but I removed first goto and now out label is placed before >>> unlock. >> >> This leaves code duplication in place, which is error prone. > > But eliminates extra goto label that is used for exactly one case. Two cases: explicitly jumping to it and reaching it from the preceeding statement. If it was only reached in one case, then it would be pointless. > Once we grow at least one more error condition that doesn't need > unlocking and I'm fine with adding it. There is code duplication present right now. >>>> diff --git a/sys/kern/sys_capability.c b/sys/kern/sys_capability.c >>>> index e3622b0..2306811 100644 >>>> --- a/sys/kern/sys_capability.c >>>> +++ b/sys/kern/sys_capability.c >>>> @@ -409,10 +409,8 @@ sys_cap_ioctls_get(struct thread *td, struct cap_ioctls_get_args *uap) >>>> if (error != 0) >>>> goto out; >>>> } >>>> - if (fdep->fde_nioctls == -1) >>>> - td->td_retval[0] = INT_MAX; >>>> - else >>>> - td->td_retval[0] = fdep->fde_nioctls; >>>> + td->td_retval[0] = >>>> + fdep->fde_nioctls != -1 ? fdep->fde_nioctls : INT_MAX; >>>> error = 0; >>>> >>>> out: >>> >>> Well, IMHO my version is more readable, especially in the first case. >> >> I had to read these lines very carefully to be sure that they actually assign to the same variables. >> Code duplication is really hurts readability. > > Trying to squeeze as much as possible into one line and then breaking > the line into three doesn't cure readability either, IMHO. > It's probably a matter of taste, but my version is more readable for me. The version with the if-else is simply a different way to break the line. It just does it with more code duplication. > Ok, I applied your change, after looking at it more it definiately is > simpler, although I don't think ?:'s result is boolean, but that's not > a big deal. The result type of ?: is whatever the combined type of the second and third operand of the ?: is. The result type of all logical and comparison operators is int, so the result is int (with a hint of boolean, because the result of these operators is always 0 or 1). Christoph From owner-freebsd-arch@FreeBSD.ORG Wed Feb 27 22:15:53 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 94C28251 for ; Wed, 27 Feb 2013 22:15:53 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) by mx1.freebsd.org (Postfix) with ESMTP id 2FAC3681 for ; Wed, 27 Feb 2013 22:15:52 +0000 (UTC) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.5/8.14.5) with ESMTP id r1RMFqUv020229; Wed, 27 Feb 2013 16:15:52 -0600 (CST) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.5/8.14.5/Submit) id r1RMFqqW020228; Wed, 27 Feb 2013 16:15:52 -0600 (CST) (envelope-from brooks) Date: Wed, 27 Feb 2013 16:15:52 -0600 From: Brooks Davis To: Warner Losh Subject: Re: [RFC] external compiler support Message-ID: <20130227221552.GC19594@lor.one-eyed-alien.net> References: <20130227003517.GB7348@lor.one-eyed-alien.net> <28404C12-67F3-44F0-AB28-02B749472873@bsdimp.com> <51BB3E17-128A-4989-B272-D8B40D4B854B@bsdimp.com> <20130227190804.GB17489@lor.one-eyed-alien.net> <13FB8CB0-9937-4BD8-AE89-0D24494D8663@bsdimp.com> <20130227214445.GA19594@lor.one-eyed-alien.net> <1CC1DB5A-E87A-456C-AD2C-E203146BB736@bsdimp.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2JFBq9zoW8cOFH7v" Content-Disposition: inline In-Reply-To: <1CC1DB5A-E87A-456C-AD2C-E203146BB736@bsdimp.com> 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: Wed, 27 Feb 2013 22:15:53 -0000 --2JFBq9zoW8cOFH7v Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 27, 2013 at 02:47:59PM -0700, Warner Losh wrote: >=20 > On Feb 27, 2013, at 2:44 PM, Brooks Davis wrote: >=20 > > On Wed, Feb 27, 2013 at 02:01:42PM -0700, Warner Losh wrote: > >>=20 > >> On Feb 27, 2013, at 12:08 PM, Brooks Davis wrote: > >>=20 > >>> On Wed, Feb 27, 2013 at 09:08:05AM -0700, Warner Losh wrote: > >>>> Ooops, forgot to add one item.. > >>>>=20 > >>>>=20 > >>>> On Feb 27, 2013, at 8:57 AM, Warner Losh wrote: > >>>>=20 > >>>>>=20 > >>>>> On Feb 26, 2013, at 5:35 PM, Brooks Davis wrote: > >>>>>=20 > >>>>>> Below (and at http://people.freebsd.org/~brooks/patches/xcc.diff) = you > >>>>>> can find an initial patch with proposed commit for external compil= er > >>>>>> support. It relies on the existing cross binutils as I'm finding = that > >>>>>> the two are fairly separable. With this patch I've been able to b= uild > >>>>>> from amd64 to arm, amd64, and i386 using clang from the lang/clang= -devel > >>>>>> port. I've also compiled the tree with a customized clang being > >>>>>> developed at the University of Cambridge. > >>>>>=20 > >>>>> Cool! > >>>>>=20 > >>>>>> The patch is untested with gcc. > >>>>>=20 > >>>>> I'd like to see it tested with gcc :) > >>>>>=20 > >>>>>> Does this seem like a reasonable approach? I do plan to look at e= xternal > >>>>>> binutils support, but it's not on the critical path for our curren= t work > >>>>>> so I've opted to avoid it for now. > >>>>>=20 > >>>>> The patches I posted a few months ago had that as well... > >>>>>=20 > >>>>>> As a bonus for those who don't need an external compiler, but do r= un > >>>>>> make buildworld frequently, the XCC, XCXX, and XCPP variables can = be set > >>>>>> to the location of the installed base system compiler to avoid bui= lding > >>>>>> the compiler twice during buildworld. > >>>>>=20 > >>>>> I think this will work, but it is kludgy. I had created a __X=3D which was prepended to ${CC}, et al, in sys.mk. It was only def= ined when you set CROSS_COMPILER_PATH (or EXTERNAL_COMPILER_PATH, I forget)= during the cross building stage. It also had the advantage of making exter= nal cross binutils available. Your patch could fairly easily use this inter= face instead of having to set 3 different variables, which will morph to 10= when you add binutil support. > >>>>=20 > >>>=20 > >>> I think something like this will have to be done for binutils given t= he > >>> way -B works, but I don't think it's workable in the general compiler > >>> case because I want to be able to use gcc46 or a future clang33 or > >>> similar as CC without changing the system compiler. Ideally I'd > >>> also like to support clang's method of finding appropriate binutils > >>> by looking first for /binutils/path/${TARGET_TRIPLE}-tool and then > >>> /binutils/path/tool. > >>=20 > >> I didn't know that clang did this, but that's certainly doable. > >=20 > > The key is that for it to work we need to set each tool's name > > individually. > >=20 > >>> As a strawman, let's say we add a CROSS_COMPILER_PATH and a > >>> CROSS_BINUTILS_PATH. The former will set XCC, XCXX, and XCPP if they > >>> are unset. The latter will control -B and set the various binutils > >>> variables (XNM, XLD, etc). > >>=20 > >> I'm not sure I like splitting things like that. It is unnatural. > >=20 > > That's the traditional view with lots of historic merit. At least in > > the short term it's not a useful view for me. I want to be able to > > use our existing infrastructure to build a cross binutils and then use > > it with an external compiler. In a clang world, we currently have one > > compiler and many binutils unless we gratuitously build many compilers > > as the FreeBSD build system currently does. Some day we will likely ha= ve > > an all-llvm toolchain available and then we will have one toolchain for > > all supported architectures. > >=20 > > I suppose could hack what I want to do into the traditional single > > toolchain world view by build a mips64 xdev toolchain and then building > > a linkfarm and/or set of wrapper scripts to it and the clang I want to > > include, but that seems problematic from a reproducability perspective > > (not to mention performance if I need wrappers to set -B). > >=20 > > Having a CROSS_TOOLCHAIN_PATH path that sets both would probably be a > > useful compromise in this regard. >=20 > Are you suggesting something like: >=20 > CROSS_COMPILER_PATH?=3D${CROSS_TOOLCHAIN_PATH} > CROSS_BINUTILS_PATH?=3D${CROSS_TOOLCHAIN_PATH} >=20 > If so, I'd agree, that would be a very useful compromise: hits my ease of= use issues, and lets you do what you need on the theory that others will l= ikely need it too. That's exactly what I'm thinking. I hope a lot of the cruft in Makefile.inc1 goes away as Simon's work is integrated, but for now I figure a little more won't hurt much... -- Brooks --2JFBq9zoW8cOFH7v Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iD8DBQFRLoWXXY6L6fI4GtQRAjETAJ9yGx7u7OUqSMbLudSYWpG56zUPUwCgz5XI quxOKx98nPm1gO6cu+3ODzA= =b67M -----END PGP SIGNATURE----- --2JFBq9zoW8cOFH7v-- From owner-freebsd-arch@FreeBSD.ORG Wed Feb 27 22:41: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 2E60796B for ; Wed, 27 Feb 2013 22:41:28 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by mx1.freebsd.org (Postfix) with ESMTP id 95B9A7E6 for ; Wed, 27 Feb 2013 22:41:27 +0000 (UTC) Received: from mailout-de.gmx.net ([10.1.76.24]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0LtC3J-1UqJCf2K6t-012qYc for ; Wed, 27 Feb 2013 23:41:26 +0100 Received: (qmail invoked by alias); 27 Feb 2013 22:41:22 -0000 Received: from p5B131D5E.dip.t-dialin.net (EHLO rotluchs.lokal) [91.19.29.94] by mail.gmx.net (mp024) with SMTP; 27 Feb 2013 23:41:22 +0100 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX1+2NUlEGQ62YajzjwmtLOheKxPP/6YI/KMGxFyW8C cOX/IJMcQ0P7NJ Message-ID: <512E8B82.5040801@gmx.de> Date: Wed, 27 Feb 2013 23:41:06 +0100 From: Christoph Mallon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130222 Thunderbird/17.0.3 MIME-Version: 1.0 To: Warner Losh Subject: Re: Large Capsicum patch for review. References: <20130213025547.GA2025@garage.freebsd.pl> <20130213230221.GB1375@garage.freebsd.pl> <20130223221116.GR1377@garage.freebsd.pl> <5129ADC5.5040306@gmx.de> <20130224193058.GW1377@garage.freebsd.pl> <512B3E5C.2090506@gmx.de> <61FF31A0-7051-4FAE-8399-76585B1D5018@bsdimp.com> In-Reply-To: <61FF31A0-7051-4FAE-8399-76585B1D5018@bsdimp.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 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: Wed, 27 Feb 2013 22:41:28 -0000 On 25.02.2013 15:21, Warner Losh wrote: > On Feb 25, 2013, at 3:35 AM, Christoph Mallon wrote: >> On 24.02.2013 20:30, Pawel Jakub Dawidek wrote: >>> Nope, but I'm using some script to generate patch(1)-compatbile diff >>> from a perforce diff. >> >> Ugh, why is p4 still in use, if it is just a hassle and hides history? > > Because it is the only VCS that doesn't suck at merging? While git, hg and svn do a passing fair job, they all suck compared to perforce. Uh, no. git's and mercurial's merging logics are reliable and fast. The fact, that a merge was performed, is encoded into the structure of the history, which makes the history a directed acyclic graph, not just a simple tree. This information is considered when performing merges. Further, there is some logic to handle cherry picks. Another important aspect is, that you prepare merge commits (and in fact every commit) locally, so if something went wrong, which shows up during testing, you can correct it locally and then just publish the finished, correct commit. So commiting in general is not an open-heart surgery thing, which is great benefit. Since svn grew recording mergeinfo (in 1.5, if I remember correctly), it works ok, too, but it is really, really slow and has some other problems. Before 1.5 it was pretty much the same as cvs, i.e. it recorded only the branch point. For repeated merges, this meant, it tried to merge again the same stuff starting at the branching point, which lead to conflicts with later changes at the same places. So you had to manually specify, what should be merged. Using git-svn works really well and provides you with most benefits, which git has to offer, while using svn as the public repository. I have no experience with other systems like bzr or darcs, but from reading I gather, that they record sufficient metainformation, too. Even the marketing guys of p4 have a hard time to justify p4 compared to git. Read their git and p4 "comparison" (www.perforce.com/sites/default/files/pdf/perforce-git-comparison.pdf), it's quite funny, if you know how to interpret it. Christoph From owner-freebsd-arch@FreeBSD.ORG Wed Feb 27 22:51: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 589EFC0E for ; Wed, 27 Feb 2013 22:51: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 C46D9887 for ; Wed, 27 Feb 2013 22:51: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 BD1006C1; Wed, 27 Feb 2013 23:48:40 +0100 (CET) Date: Wed, 27 Feb 2013 23:52:58 +0100 From: Pawel Jakub Dawidek To: Christoph Mallon Subject: Re: Large Capsicum patch for review. Message-ID: <20130227225257.GF1380@garage.freebsd.pl> References: <20130213025547.GA2025@garage.freebsd.pl> <20130213230221.GB1375@garage.freebsd.pl> <20130223221116.GR1377@garage.freebsd.pl> <5129ADC5.5040306@gmx.de> <512A2CA0.2050509@gmx.de> <20130224235936.GX1377@garage.freebsd.pl> <512B3DBB.4080909@gmx.de> <20130225215004.GA1375@garage.freebsd.pl> <512E8572.6050107@gmx.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SxgehGEc6vB0cZwN" Content-Disposition: inline In-Reply-To: <512E8572.6050107@gmx.de> 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: Wed, 27 Feb 2013 22:51:43 -0000 --SxgehGEc6vB0cZwN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 27, 2013 at 11:15:14PM +0100, Christoph Mallon wrote: > On 25.02.2013 22:50, Pawel Jakub Dawidek wrote: > > Using three types here is not inconsistent, it is a common practise. >=20 > Using three different types for the same context /is/ inconsistent. >=20 > > Check out even read(2) and write(2) - they take size as size_t, as there > > is no need for a negative size, but they return ssize_t, because they > > can return -1 if an error occured. This is exactly what I do in > > cap_ioctls_get(). >=20 > "Common practise" does not automatically turn something into a good idea. This is what we use for syscalls in FreeBSD and I want my code to be consistent with the rest of the code. We really don't want to make every syscall to be implemented in its own special way following creation's day trends. I also do like how read(2) and write(2) use size_t and ssize_t. > > I use size_t as this is preferred type for size, but I don't need size_t > > for iterator, because I know the value will never need more than 16 > > bits, so I use int as a more CPU-friendly type. >=20 > See my earlier mail about this. I changed int/u_int to long/u_long, but that's all I can do. Using ssize_t/size_t as iterators types just looks odd to me. > > The entire history is there, nothing is lost: > >=20 > > http://p4db.freebsd.org/ >=20 > So effectively it is lost. > FreeBSD's history is recorded in its SVN respository. > Throwing big patch bombs into it only makes it harder to comprehend chang= es. Well, by moving experimental development to perforce allowed to stabilize FreeBSD-HEAD greately, which was a huge step forward for the project as more people can run HEAD these days than in the past. Now with SVN many people moved their development to SVN, but I personally love perforce and in my opinion it is just so much better than anything else I've tried over the years (CVS, SVN, hg, git). I hope you agree that I'm free to choose the best tools to do my job. Sadly it means the full history is harder to obtain, but on the other hand history is not poluted with all small commits that don't really help to review the patch, but introduce unnecessary bloat. FYI, There were ~400 perforce commits during that work. I don't think people would be happy if I'd commit them to SVN one by one. > > Your changes were pretty simple, so they look nice as separate commits. >=20 > It's the other way round: > The changes are simple, because they are separate commits, which do a sin= gle thing each. > So it is clear what to look for in each commit. No. Your changes were simple. Period. I can export all 400 changes for you to review, but I'm pretty sure it would not make the review any easier, quite the opposite. Especially that after reviewing first 50 changes you could realize that it was a failed experiment and the work was thrown away later during development. > > Trying to squeeze as much as possible into one line and then breaking > > the line into three doesn't cure readability either, IMHO. > > It's probably a matter of taste, but my version is more readable for me. >=20 > The version with the if-else is simply a different way to break the line. > It just does it with more code duplication. The point is that each line can be read separately. > > Ok, I applied your change, after looking at it more it definiately is > > simpler, although I don't think ?:'s result is boolean, but that's not > > a big deal. >=20 > The result type of ?: is whatever the combined type of the second and thi= rd operand of the ?: is. Not really. uint8_t a, b; a =3D b =3D 0; printf("%zu\n", sizeof(true ? a : b)); Result: 4 > The result type of all logical and comparison operators is int, so the re= sult is int (with a hint of boolean, because the result of these operators = is always 0 or 1). Right, but something like the following makes me sad: int intval; void *ptr; char ch; if (!intval) ; if (ptr) ; if (ch) ; I much prefer explicit comparison and would love to see clang being extended to issue a warning when non-boolean is checked: if (intval =3D=3D 0) ; if (ptr !=3D NULL) ; if (ch !=3D '\0') ; --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --SxgehGEc6vB0cZwN Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlEujkkACgkQForvXbEpPzT27QCfazfYUruA6CKB3mP26EmkI1mU /QwAoKWIzFm4XWkmDnOXJMT5begXE0sW =yi23 -----END PGP SIGNATURE----- --SxgehGEc6vB0cZwN-- From owner-freebsd-arch@FreeBSD.ORG Wed Feb 27 23:08:25 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 5CC33476 for ; Wed, 27 Feb 2013 23:08:25 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-gg0-x233.google.com (mail-gg0-x233.google.com [IPv6:2607:f8b0:4002:c02::233]) by mx1.freebsd.org (Postfix) with ESMTP id 218D6964 for ; Wed, 27 Feb 2013 23:08:25 +0000 (UTC) Received: by mail-gg0-f179.google.com with SMTP id h4so177702ggn.10 for ; Wed, 27 Feb 2013 15:08:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=euUjMpWCxz2vmuKHJn0EOL6BjyomMjXpl7zXX0WAOKY=; b=p02U4Q9ujIEGgtwmHPHQha9RkTvO28/80zU+Yc+ZXJFBa75gGPbl4UWVyWxPZWaztK wmO09u0mTQ2na0R+XkrGNLobhO94wafJ9zDl6rJr+WT3GobDs8ao/WK7EaW5xrdlS/Y5 paB8jphwFTwjbRJutXzuUZ0fxLfHuaDDCyHdcfxCIcHTfgYcK39YErB0pTe1TEfiw2si GuboXxRnIK9jWm7krhnUzmE3T2NQ3vUPbC+40bbPqwrxc8tR0zZ/VWr9lTUYhatBjBAo fsPwx8Xq8/y4d3RD7DXQcUE8XFOSrSKbBwHLYq9Ol4fWiO5a1KeaRp21t9PtbSujUX/f U9yg== X-Received: by 10.236.125.77 with SMTP id y53mr3213126yhh.14.1362006504392; Wed, 27 Feb 2013 15:08:24 -0800 (PST) Received: from monkey-bot.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPS id k2sm6131218yhn.26.2013.02.27.15.08.22 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Feb 2013 15:08:23 -0800 (PST) Sender: Warner Losh Subject: Re: Large Capsicum patch for review. Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <512E8B82.5040801@gmx.de> Date: Wed, 27 Feb 2013 16:08:20 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6DB9C19D-C8E8-4386-8D03-6D4EC1523C1D@bsdimp.com> References: <20130213025547.GA2025@garage.freebsd.pl> <20130213230221.GB1375@garage.freebsd.pl> <20130223221116.GR1377@garage.freebsd.pl> <5129ADC5.5040306@gmx.de> <20130224193058.GW1377@garage.freebsd.pl> <512B3E5C.2090506@gmx.de> <61FF31A0-7051-4FAE-8399-76585B1D5018@bsdimp.com> <512E8B82.5040801@gmx.de> To: Christoph Mallon X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQkxDCKwzG81Xci17IdgR0vPnj/Cq+gYjE2cMQfvu/1DnzY+SvlcCj7BwIZu2B6hr1Q4IoMO 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: Wed, 27 Feb 2013 23:08:25 -0000 On Feb 27, 2013, at 3:41 PM, Christoph Mallon wrote: > On 25.02.2013 15:21, Warner Losh wrote: >> On Feb 25, 2013, at 3:35 AM, Christoph Mallon wrote: >>> On 24.02.2013 20:30, Pawel Jakub Dawidek wrote: >>>> Nope, but I'm using some script to generate patch(1)-compatbile = diff >>>> from a perforce diff. >>>=20 >>> Ugh, why is p4 still in use, if it is just a hassle and hides = history? >>=20 >> Because it is the only VCS that doesn't suck at merging? While git, = hg and svn do a passing fair job, they all suck compared to perforce. >=20 > Uh, no. > git's and mercurial's merging logics are reliable and fast. You must be using a different definition of 'reilable' than I'm = accustomed to. It certainly is fast, but isn't as reliable and robust = and perforce. Having used both heavily in branched environments, I can = state unequivocally that perforce of 2003 did a better job than = mercurial does in 2013. I've had more problems with mercurial than I = ever had with perforce. > The fact, that a merge was performed, is encoded into the structure of = the history, which makes the history a directed acyclic graph, not just = a simple tree. > This information is considered when performing merges. > Further, there is some logic to handle cherry picks. > Another important aspect is, that you prepare merge commits (and in = fact every commit) locally, so if something went wrong, which shows up = during testing, you can correct it locally and then just publish the = finished, correct commit. > So commiting in general is not an open-heart surgery thing, which is = great benefit. Sure, it is a lot better than CVS, but it is no perforce. while = mercurial does let me prepare the commit(s) locally, which is a plus = over perforce, it has mismerged things too often for me to not complain = when you use the word 'reliable'. > Since svn grew recording mergeinfo (in 1.5, if I remember correctly), = it works ok, too, but it is really, really slow and has some other = problems. > Before 1.5 it was pretty much the same as cvs, i.e. it recorded only = the branch point. > For repeated merges, this meant, it tried to merge again the same = stuff starting at the branching point, which lead to conflicts with = later changes at the same places. > So you had to manually specify, what should be merged. Newer subversions are only marginally worse than mercurial from what = I've done, but my recent experience has been much more slanted to = mercurial than subversion, so that impression suffers from a small = sample size. > Using git-svn works really well and provides you with most benefits, = which git has to offer, while using svn as the public repository. > I have no experience with other systems like bzr or darcs, but from = reading I gather, that they record sufficient metainformation, too. > Even the marketing guys of p4 have a hard time to justify p4 compared = to git. > Read their git and p4 "comparison" = (www.perforce.com/sites/default/files/pdf/perforce-git-comparison.pdf), = it's quite funny, if you know how to interpret it. Can't speak to git in any of this. I've used it only lightly to snag = other people's software. I do know what issues I've encountered with = mercurial. Don't get me wrong, there's a number of nice features in hg, = and it has been less problematic than svn or cvs, but much more of a = pita than p4. Can't beat the price, for some environments it is perfect, = but heavy branching it is still somewhat weaker than my perforce = branching experience. Warner= From owner-freebsd-arch@FreeBSD.ORG Wed Feb 27 23:28:21 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 4B34FA42; Wed, 27 Feb 2013 23:28:21 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by mx1.freebsd.org (Postfix) with ESMTP id 0DC88A2C; Wed, 27 Feb 2013 23:28:20 +0000 (UTC) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKUS6Wk0QVvHslgJusApkdR9RBSaZXN6jG@postini.com; Wed, 27 Feb 2013 15:28:21 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 27 Feb 2013 15:26:33 -0800 Received: from chaos.jnpr.net (chaos.jnpr.net [172.24.29.229]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id r1RNQW356767; Wed, 27 Feb 2013 15:26:32 -0800 (PST) (envelope-from sjg@juniper.net) Received: from chaos.jnpr.net (localhost [127.0.0.1]) by chaos.jnpr.net (Postfix) with ESMTP id 74C2F58096; Wed, 27 Feb 2013 15:26:32 -0800 (PST) To: Brooks Davis Subject: Re: [RFC] external compiler support In-Reply-To: <20130227220520.GB19594@lor.one-eyed-alien.net> References: <20130227003517.GB7348@lor.one-eyed-alien.net> <28404C12-67F3-44F0-AB28-02B749472873@bsdimp.com> <51BB3E17-128A-4989-B272-D8B40D4B854B@bsdimp.com> <20130227175006.A604A58096@chaos.jnpr.net> <20130227195807.GA19255@lor.one-eyed-alien.net> <20130227202822.8F53B58096@chaos.jnpr.net> <20130227220520.GB19594@lor.one-eyed-alien.net> Comments: In-reply-to: Brooks Davis message dated "Wed, 27 Feb 2013 16:05:20 -0600." From: "Simon J. Gerraty" X-Mailer: MH-E 7.82+cvs; nmh 1.3; GNU Emacs 22.3.1 Date: Wed, 27 Feb 2013 15:26:32 -0800 Message-ID: <20130227232632.74C2F58096@chaos.jnpr.net> MIME-Version: 1.0 Content-Type: text/plain 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: Wed, 27 Feb 2013 23:28:21 -0000 On Wed, 27 Feb 2013 16:05:20 -0600, Brooks Davis writes: >I like the end goal, but it doesn't feel like taking this route gets me >any less code in Makefile.inc1 in the short term. Makefile.inc1 are perhaps necessary for the short term. I'm not using them at all, but also not yet building the entire universe. >I don't like that for now it forces me to use traditional names for >all these tools (they must match the name of the native tools) and to >install them next to each other (or create a link farm to do that). Sorry, I might be caffeine deficient, can you elabortate? I don't see how that follows. Anything done via *.mk can be overridden via Makefile.inc1 and if need be you can always use extra variables. >This seems to make it unnecessarily difficult to perform any kind of >casual compiler testing across the whole tree. You are presumably wanting to separately control the basename of the compiler as well as its location ? Separate variables? Presumably by changing compiler you also need to control CFLAGS... eg. I found it necessary to add CFLAGS_LAST.clang += -isystem ${STAGE_OBJTOP}/usr/include/clang/3.2 CXXFLAGS_LAST += ${CFLAGS_LAST.${COMPILER_TYPE}} You could get carried away with indirection... CLANG_NAME?= clang32 GCC_NAME?= gcc42 COMPILER_TYPE.c ?= gcc COMPILER_TYPE.cc ?= clang COMPILER.c ?= ${${COMPILER_TYPE.c:tu}_NAME} CC ?= ${COMPILER_PATH.${COMPILER.c}}${COMPILER.c} which lets you indivitually control the type of compiler its name is path etc >> >Otherwise /rescue fails as do several things in /boot. >>=20 >> That would presumably be bugs in the relevant makefiles no? > >The problem in both cases is that they need tight control of C(XX)FLAGS >in order to generate small or static binaries. There are any number Again can you elaborate - I just took a quick look and didn't see anything under rescue/ that wasn't a simple addition to CFLAGS. >Making the options part of CC works today and avoids needing to modify >many makefiles whose products I can't test easily or in many cases at >all. Notionally I feel it's equivalent to creating a wrapper script >around each tool to change a couple defaults without the overhead or >hassle. So long as you don't have to do it via Makefile.inc1 that may be so. >While I could test the /rescue case, fixing it involves modifying >cruchgen and my first attempt to look at it lead me to run away quickly. :) I'm obviously missing something, so before you dive into that let's get on the same page ;-) From owner-freebsd-arch@FreeBSD.ORG Wed Feb 27 23:59:53 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 A72E5DB7 for ; Wed, 27 Feb 2013 23:59:53 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) by mx1.freebsd.org (Postfix) with ESMTP id 8617AB0D for ; Wed, 27 Feb 2013 23:59:52 +0000 (UTC) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.5/8.14.5) with ESMTP id r1RNxrvf020807; Wed, 27 Feb 2013 17:59:53 -0600 (CST) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.5/8.14.5/Submit) id r1RNxqd4020806; Wed, 27 Feb 2013 17:59:52 -0600 (CST) (envelope-from brooks) Date: Wed, 27 Feb 2013 17:59:52 -0600 From: Brooks Davis To: "Simon J. Gerraty" Subject: Re: [RFC] external compiler support Message-ID: <20130227235952.GE19594@lor.one-eyed-alien.net> References: <20130227003517.GB7348@lor.one-eyed-alien.net> <28404C12-67F3-44F0-AB28-02B749472873@bsdimp.com> <51BB3E17-128A-4989-B272-D8B40D4B854B@bsdimp.com> <20130227175006.A604A58096@chaos.jnpr.net> <20130227195807.GA19255@lor.one-eyed-alien.net> <20130227202822.8F53B58096@chaos.jnpr.net> <20130227220520.GB19594@lor.one-eyed-alien.net> <20130227232632.74C2F58096@chaos.jnpr.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EXKGNeO8l0xGFBjy" Content-Disposition: inline In-Reply-To: <20130227232632.74C2F58096@chaos.jnpr.net> 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: Wed, 27 Feb 2013 23:59:53 -0000 --EXKGNeO8l0xGFBjy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 27, 2013 at 03:26:32PM -0800, Simon J. Gerraty wrote: >=20 > On Wed, 27 Feb 2013 16:05:20 -0600, Brooks Davis writes: > >I like the end goal, but it doesn't feel like taking this route gets me > >any less code in Makefile.inc1 in the short term. >=20 > Makefile.inc1 are perhaps necessary for the short term. > I'm not using them at all, but also not yet building the entire > universe. >=20 > >I don't like that for now it forces me to use traditional names for > >all these tools (they must match the name of the native tools) and to > >install them next to each other (or create a link farm to do that). >=20 > Sorry, I might be caffeine deficient, can you elabortate? > I don't see how that follows. > Anything done via *.mk can be overridden via Makefile.inc1 > and if need be you can always use extra variables. If I need to override CC or the like in Makefile.inc1 then all this indirection buys me nothing since I immediately throw it away. As things stand I can't override them at all because the ${CC} we use to build host tools must be the same as the one we use to cross build. We currently contrive to make that work by unconditionally stuffing a cross compiler into ${WORLDTMP}. My patches mostly exist to break that tie between the two ${CC}s. I'm not arguing against the proposed indirection at all. The long term benefits are quite clear, it just doesn't do me much good in the current world order. > >This seems to make it unnecessarily difficult to perform any kind of > >casual compiler testing across the whole tree. >=20 > You are presumably wanting to separately control the basename of the > compiler as well as its location ? Yes. It's not critical, but it would be nice to make it easy for people to do this sort of thing. > Separate variables? > Presumably by changing compiler you also need to control CFLAGS... > eg. I found it necessary to add >=20 > CFLAGS_LAST.clang +=3D -isystem ${STAGE_OBJTOP}/usr/include/clang/3.2 > CXXFLAGS_LAST +=3D ${CFLAGS_LAST.${COMPILER_TYPE}} Hmm, I've not had to do that, but it seems likely that similar things could be required. > You could get carried away with indirection... >=20 > CLANG_NAME?=3D clang32 > GCC_NAME?=3D gcc42 >=20 > COMPILER_TYPE.c ?=3D gcc > COMPILER_TYPE.cc ?=3D clang >=20 > COMPILER.c ?=3D ${${COMPILER_TYPE.c:tu}_NAME} >=20 > CC ?=3D ${COMPILER_PATH.${COMPILER.c}}${COMPILER.c} >=20 > which lets you indivitually control the type of compiler its name is > path etc=20 >=20 > >> >Otherwise /rescue fails as do several things in /boot. > >>=3D20 > >> That would presumably be bugs in the relevant makefiles no? > > > >The problem in both cases is that they need tight control of C(XX)FLAGS > >in order to generate small or static binaries. There are any number >=20 > Again can you elaborate - I just took a quick look and didn't see=20 > anything under rescue/ that wasn't a simple addition to CFLAGS. I think remember the issue now. The problem was that I was setting a variable (SYSROOT) that would cause additions to CFLAGS. Because the crunch environment is set by crunchgen I wasn't able to figure out a good way to pass that variable in such that changes were made to CFLAGS. That may well be a lack of imagination or understanding of the combination of bsd.crunchgen.mk and crunchgen, but it wasn't at all clear how to even get started. An example of a problem boot related Makefile is sys/boot/i386/gptboot/Makefile. -- Broks --EXKGNeO8l0xGFBjy Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iD8DBQFRLp34XY6L6fI4GtQRAq1zAJsEzU2jCHzSHrde06SNGbU3rm20hQCeJ68Q 7Y1azPwTI0uoFPEQgUPXxvU= =XnZa -----END PGP SIGNATURE----- --EXKGNeO8l0xGFBjy-- From owner-freebsd-arch@FreeBSD.ORG Thu Feb 28 00:02:43 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 83AFDE6B for ; Thu, 28 Feb 2013 00:02:43 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) by mx1.freebsd.org (Postfix) with ESMTP id 3E07BB20 for ; Thu, 28 Feb 2013 00:02:40 +0000 (UTC) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.5/8.14.5) with ESMTP id r1S02fNX020845; Wed, 27 Feb 2013 18:02:41 -0600 (CST) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.5/8.14.5/Submit) id r1S02fhO020844; Wed, 27 Feb 2013 18:02:41 -0600 (CST) (envelope-from brooks) Date: Wed, 27 Feb 2013 18:02:41 -0600 From: Brooks Davis To: Warner Losh Subject: Re: [RFC] external compiler support Message-ID: <20130228000241.GF19594@lor.one-eyed-alien.net> References: <20130227003517.GB7348@lor.one-eyed-alien.net> <28404C12-67F3-44F0-AB28-02B749472873@bsdimp.com> <51BB3E17-128A-4989-B272-D8B40D4B854B@bsdimp.com> <20130227190804.GB17489@lor.one-eyed-alien.net> <13FB8CB0-9937-4BD8-AE89-0D24494D8663@bsdimp.com> <20130227214445.GA19594@lor.one-eyed-alien.net> <1CC1DB5A-E87A-456C-AD2C-E203146BB736@bsdimp.com> <20130227221552.GC19594@lor.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oPmsXEqKQNHCSXW7" Content-Disposition: inline In-Reply-To: <20130227221552.GC19594@lor.one-eyed-alien.net> 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: Thu, 28 Feb 2013 00:02:43 -0000 --oPmsXEqKQNHCSXW7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 27, 2013 at 04:15:52PM -0600, Brooks Davis wrote: > On Wed, Feb 27, 2013 at 02:47:59PM -0700, Warner Losh wrote: > >=20 > > On Feb 27, 2013, at 2:44 PM, Brooks Davis wrote: > > >>> As a strawman, let's say we add a CROSS_COMPILER_PATH and a > > >>> CROSS_BINUTILS_PATH. The former will set XCC, XCXX, and XCPP if th= ey > > >>> are unset. The latter will control -B and set the various binutils > > >>> variables (XNM, XLD, etc). > > >>=20 > > >> I'm not sure I like splitting things like that. It is unnatural. > > >=20 > > > That's the traditional view with lots of historic merit. At least in > > > the short term it's not a useful view for me. I want to be able to > > > use our existing infrastructure to build a cross binutils and then use > > > it with an external compiler. In a clang world, we currently have one > > > compiler and many binutils unless we gratuitously build many compilers > > > as the FreeBSD build system currently does. Some day we will likely = have > > > an all-llvm toolchain available and then we will have one toolchain f= or > > > all supported architectures. > > >=20 > > > I suppose could hack what I want to do into the traditional single > > > toolchain world view by build a mips64 xdev toolchain and then buildi= ng > > > a linkfarm and/or set of wrapper scripts to it and the clang I want to > > > include, but that seems problematic from a reproducability perspective > > > (not to mention performance if I need wrappers to set -B). > > >=20 > > > Having a CROSS_TOOLCHAIN_PATH path that sets both would probably be a > > > useful compromise in this regard. > >=20 > > Are you suggesting something like: > >=20 > > CROSS_COMPILER_PATH?=3D${CROSS_TOOLCHAIN_PATH} > > CROSS_BINUTILS_PATH?=3D${CROSS_TOOLCHAIN_PATH} > >=20 > > If so, I'd agree, that would be a very useful compromise: hits my ease = of use issues, and lets you do what you need on the theory that others will= likely need it too. >=20 > That's exactly what I'm thinking. Here's a rework with that implemented. I'm not 100% sure I got the list of binutils right, but it notionally supports both my usecase and a more classic cross compiler set. -- Brooks MFP4 222356, 222371, 222375, 222391, 222403, 222407, 222411, 222446 Add support for an external cross compiler. The cross compiler is specified by passing the XCC, XCXX, and XCPP variables (corresponding to CC, CXX, and CPP) to buildworld/buildkernel. The compiler must be clang or be configured to target the appropriate architecture. To speed build times, if XCC is an absolute path or WITHOUT_CROSS_COMPILER is defined then no cross compiler will be built during the cross-tools stage. To facilitate the use of unmodified external compilers, a WITHOUT_FORMAT_EXTENSIONS option is available to supress printf format checking. As a short-term measure, supress a few new clang warnings during kernel builds. Sponsored by: DARPA, AFRL Reviewed by: xxx --- ../../freebsd/src/Makefile.inc1 2013-02-26 21:31:09.000000000 +0000 +++ ./Makefile.inc1 2013-02-27 23:31:46.000000000 +0000 @@ -280,15 +280,61 @@ .if ${MK_CDDL} =3D=3D "no" WMAKEENV+=3D NO_CTF=3D1 .endif -.if ${CC:T:Mgcc} =3D=3D "gcc" + +.if defined(CROSS_TOOLCHAIN_PATH) +CROSS_COMPILER_PATH?=3D${CROSS_TOOLCHAIN_PATH} +CROSS_BINUTILS_PATH?=3D${CROSS_TOOLCHAIN_PATH} +.endif +XCOMPILERS=3D CC CXX CPP +.for COMPILER in ${XCOMPILERS} +.if defined(CROSS_COMPILER_PATH) +X${COMPILER}?=3D ${CROSS_COMPILER_PATH}/${${COMPILER}} +.else +X${COMPILER}?=3D ${${COMPILER}} +.endif +.endfor +XBINUTILS=3D AS AR LD NM OBJDUMP RANLIB STRINGS +.for BINUTIL in ${XBINUTILS} +.if defined(CROSS_BINUTILS_PATH) +X${BINUTIL}?=3D ${CROSS_BINUTILS_PATH}/${${BINUTIL}} +.else +X${BINUTIL}?=3D ${${BINUTIL}} +.endif +.endfor +WMAKEENV+=3D CC=3D"${XCC} ${XFLAGS}" CXX=3D"${XCXX} ${XFLAGS}" \ + CPP=3D"${XCPP} ${XFLAGS}" \ + AS=3D"${XAS}" AR=3D"${XAR}" LD=3D"${XLD}" NM=3D${XNM} \ + OBJDUMP=3D${XOBJDUMP} RANLIB=3D${RANLIB} STRINGS=3D${XSTRINGS} + +.if ${XCC:T:Mgcc} =3D=3D "gcc" WMAKE_COMPILER_TYPE=3D gcc -.elif ${CC:T:Mclang} =3D=3D "clang" +.elif ${XCC:T:Mclang} =3D=3D "clang" WMAKE_COMPILER_TYPE=3D clang .elif ${MK_CLANG_IS_CC} =3D=3D "no" WMAKE_COMPILER_TYPE=3D gcc .else WMAKE_COMPILER_TYPE=3D clang .endif + +.if ${XCC:M/*} +XFLAGS=3D --sysroot=3D${WORLDTMP} +.if defined(CROSS_BINUTILS_PATH) +XFLAGS+=3D -B${CROSS_BINUTILS_PATH} +.else +XFLAGS+=3D -B${WORLDTMP}/usr/bin +.endif +.if ${TARGET_ARCH} !=3D ${MACHINE_ARCH} && ${WMAKE_COMPILER_TYPE} =3D=3D "= clang" +.if (${TARGET_ARCH} =3D=3D "arm" || ${TARGET_ARCH} =3D=3D "armv6") && \ +${MK_ARM_EABI} !=3D "no" +TARGET_ABI=3D gnueabi +.else +TARGET_ABI=3D unknown +.endif +TARGET_TRIPLE?=3D ${TARGET_ARCH:C/amd64/x86_64/}-${TARGET_ABI}-freebsd10.0 +XFLAGS+=3D -target ${TARGET_TRIPLE} +.endif +.endif + WMAKEENV+=3D COMPILER_TYPE=3D${WMAKE_COMPILER_TYPE} WMAKE=3D ${WMAKEENV} ${MAKE} ${WORLD_FLAGS} -f Makefile.inc1 DESTDIR=3D${= WORLDTMP} =20 @@ -321,6 +367,7 @@ =20 =20 LIB32FLAGS=3D -m32 ${LIB32CPUFLAGS} -DCOMPAT_32BIT \ + --sysroot=3D${WORLDTMP} \ -isystem ${LIB32TMP}/usr/include/ \ -L${LIB32TMP}/usr/lib32 \ -B${LIB32TMP}/usr/lib32 @@ -336,8 +383,8 @@ SHLIBDIR=3D/usr/lib32 \ COMPILER_TYPE=3D${WMAKE_COMPILER_TYPE} LIB32WMAKEFLAGS+=3D \ - CC=3D"${CC} ${LIB32FLAGS}" \ - CXX=3D"${CXX} ${LIB32FLAGS}" \ + CC=3D"${XCC} ${LIB32FLAGS}" \ + CXX=3D"${XCXX} ${LIB32FLAGS}" \ DESTDIR=3D${LIB32TMP} \ -DCOMPAT_32BIT \ -DLIBRARIES_ONLY \ @@ -1284,10 +1331,13 @@ .endif .endif =20 -.if ${MK_BINUTILS} !=3D "no" +.if ${XAS:M/*} =3D=3D "" && ${MK_BINUTILS} !=3D "no" _binutils=3D gnu/usr.bin/binutils .endif =20 +# If an full path to an external cross compiler is given, don't build +# a cross compiler. +.if ${XCC:M/*} =3D=3D "" && ${MK_CROSS_COMPILER} !=3D "no" .if ${MK_CLANG} !=3D "no" && (${MK_CLANG_IS_CC} !=3D "no" || ${CC:T:Mclang= } =3D=3D "clang") _clang=3D usr.bin/clang _clang_libs=3D lib/clang @@ -1296,6 +1346,7 @@ .if ${MK_GCC} !=3D "no" && (${MK_CLANG_IS_CC} =3D=3D "no" || ${TARGET} =3D= =3D "pc98") _cc=3D gnu/usr.bin/cc .endif +.endif =20 cross-tools: .for _tool in \ --- ../../freebsd/src/share/mk/bsd.own.mk 2013-02-15 18:49:13.000000000 +00= 00 +++ share/mk/bsd.own.mk 2013-02-26 21:10:50.000000000 +0000 @@ -262,6 +262,7 @@ CAPSICUM \ CDDL \ CPP \ + CROSS_COMPILER \ CRYPT \ CTM \ CVS \ @@ -271,6 +272,7 @@ ED_CRYPTO \ EXAMPLES \ FLOPPY \ + FORMAT_EXTENSIONS \ FORTH \ FP_LIBC \ FREEBSD_UPDATE \ --- ../../freebsd/src/sys/conf/kern.mk 2012-11-11 22:15:16.000000000 +0000 +++ sys/conf/kern.mk 2013-02-26 20:35:48.000000000 +0000 @@ -5,7 +5,7 @@ # CWARNFLAGS?=3D -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototype= s \ -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual \ - -Wundef -Wno-pointer-sign -fformat-extensions \ + -Wundef -Wno-pointer-sign ${FORMAT_EXTENTIONS} \ -Wmissing-include-dirs -fdiagnostics-show-option \ ${CWARNEXTRA} # @@ -29,7 +29,18 @@ # enough to error out the whole kernel build. Display them anyway, so the= re is # some incentive to fix them eventually. CWARNEXTRA?=3D -Wno-error-tautological-compare -Wno-error-empty-body \ - -Wno-error-parentheses-equality + -Wno-error-parentheses-equality \ + -Wno-sizeof-pointer-memaccess \ + -Wno-unused-command-line-argument \ + ${NO_WFORMAT} +.endif + +# External compilers may not support our format extensions. Allow them +# to be disabled. WARNING: format checking is disabled in this case. +.if ${MK_FORMAT_EXTENSIONS} =3D=3D "no" +NO_WFORMAT=3D -Wno-format +.else +FORMAT_EXTENTIONS=3D -fformat-extensions .endif =20 # diff -uN ../../freebsd/src/tools/build/options/WITHOUT_CROSS_COMPILER tools= /build/options/WITHOUT_CROSS_COMPILER --- ../../freebsd/src/tools/build/options/WITHOUT_CROSS_COMPILER 1970-01-01= 00:00:00.000000000 +0000 +++ tools/build/options/WITHOUT_CROSS_COMPILER 2013-02-26 21:10:50.00000000= 0 +0000 @@ -0,0 +1,3 @@ +.\" $FreeBSD$ +Set to not build a cross compiler in the cross-tools stage of +buildworld, buildkernel, etc. diff -uN ../../freebsd/src/tools/build/options/WITHOUT_FORMAT_EXTENSIONS to= ols/build/options/WITHOUT_FORMAT_EXTENSIONS --- ../../freebsd/src/tools/build/options/WITHOUT_FORMAT_EXTENSIONS 1970-01= -01 00:00:00.000000000 +0000 +++ tools/build/options/WITHOUT_FORMAT_EXTENSIONS 2013-02-26 20:35:48.00000= 0000 +0000 @@ -0,0 +1,5 @@ +.\" $FreeBSD$ +Set to not enable +.Fl fformat-extensions +when compiling the kernel. +Also disables all format checking. --oPmsXEqKQNHCSXW7 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iD8DBQFRLp6gXY6L6fI4GtQRAtfbAKDkVZmeaAmp5wOYL+wzB9V0XSPWvQCfQVXD Ntz1VNp33QyDbduLO8DlUvU= =DvTW -----END PGP SIGNATURE----- --oPmsXEqKQNHCSXW7-- From owner-freebsd-arch@FreeBSD.ORG Thu Feb 28 01:18:15 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 A78D41FC; Thu, 28 Feb 2013 01:18:15 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (pancho.soaustin.net [76.74.250.40]) by mx1.freebsd.org (Postfix) with ESMTP id 8B00FF3C; Thu, 28 Feb 2013 01:18:15 +0000 (UTC) Received: by mail.soaustin.net (Postfix, from userid 502) id ED77956074; Wed, 27 Feb 2013 19:18:08 -0600 (CST) Date: Wed, 27 Feb 2013 19:18:08 -0600 From: Mark Linimon To: Tim Kientzle Subject: Re: ARM EABI directions Message-ID: <20130228011808.GA19595@lonesome.com> References: <20130227003517.GB7348@lor.one-eyed-alien.net> <28404C12-67F3-44F0-AB28-02B749472873@bsdimp.com> <0435EF00-62B4-4389-BB3A-3351FC522C34@kientzle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0435EF00-62B4-4389-BB3A-3351FC522C34@kientzle.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Brooks Davis , 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: Thu, 28 Feb 2013 01:18:15 -0000 On Wed, Feb 27, 2013 at 09:09:15AM -0800, Tim Kientzle wrote: > Why? ARM was Tier 2 for FreeBSD 9.x, and the FreeBSD > package builds still don't support ARM packages, so I'm > not convinced that would be a problem. I had been building arm packages for several months on a loaned system until the security incident happened. To my knowledge, none of those packages or logs have been brought back online. mcl From owner-freebsd-arch@FreeBSD.ORG Thu Feb 28 01:39:41 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 EDBD3CD5; Thu, 28 Feb 2013 01:39:41 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by mx1.freebsd.org (Postfix) with ESMTP id 8533580; Thu, 28 Feb 2013 01:39:41 +0000 (UTC) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKUS61V+jIljENLcAEIqK5NJCzPU/xzgqP@postini.com; Wed, 27 Feb 2013 17:39:41 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 27 Feb 2013 17:39:17 -0800 Received: from chaos.jnpr.net (chaos.jnpr.net [172.24.29.229]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id r1S1dG323309; Wed, 27 Feb 2013 17:39:16 -0800 (PST) (envelope-from sjg@juniper.net) Received: from chaos.jnpr.net (localhost [127.0.0.1]) by chaos.jnpr.net (Postfix) with ESMTP id DF81E58096; Wed, 27 Feb 2013 17:39:15 -0800 (PST) To: Brooks Davis Subject: Re: [RFC] external compiler support In-Reply-To: <20130227235952.GE19594@lor.one-eyed-alien.net> References: <20130227003517.GB7348@lor.one-eyed-alien.net> <28404C12-67F3-44F0-AB28-02B749472873@bsdimp.com> <51BB3E17-128A-4989-B272-D8B40D4B854B@bsdimp.com> <20130227175006.A604A58096@chaos.jnpr.net> <20130227195807.GA19255@lor.one-eyed-alien.net> <20130227202822.8F53B58096@chaos.jnpr.net> <20130227220520.GB19594@lor.one-eyed-alien.net> <20130227232632.74C2F58096@chaos.jnpr.net> <20130227235952.GE19594@lor.one-eyed-alien.net> Comments: In-reply-to: Brooks Davis message dated "Wed, 27 Feb 2013 17:59:52 -0600." From: "Simon J. Gerraty" X-Mailer: MH-E 7.82+cvs; nmh 1.3; GNU Emacs 22.3.1 Date: Wed, 27 Feb 2013 17:39:15 -0800 Message-ID: <20130228013915.DF81E58096@chaos.jnpr.net> MIME-Version: 1.0 Content-Type: text/plain 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: Thu, 28 Feb 2013 01:39:42 -0000 On Wed, 27 Feb 2013 17:59:52 -0600, Brooks Davis writes: >I'm not arguing against the proposed indirection at all. The long term >benefits are quite clear, it just doesn't do me much good in the current >world order. Ah - understood. >> CFLAGS_LAST.clang +=3D -isystem ${STAGE_OBJTOP}/usr/include/clang/3.2 >> CXXFLAGS_LAST +=3D ${CFLAGS_LAST.${COMPILER_TYPE}} > >Hmm, I've not had to do that, but it seems likely that similar things >could be required. I was even more suprised to find that clang needed -isystem ${STAGE_OBJTOP}/usr/include/c++/${GCCVER:U4.2} .meta files are great for finding out what the compiler is really doing ;-) Of course all these -isystem's are needed because I use -nostdinc to avoid accidentally pulling headers from /usr/include. With sysroot support that wouldn't be necessary. >I think remember the issue now. The problem was that I was setting a >variable (SYSROOT) that would cause additions to CFLAGS. Because the >crunch environment is set by crunchgen I wasn't able to figure out a good looks like crunchgen uses 'env MAKEOBJDIRPREFIX=$(MAKEOBJDIRPREFIX) $(MAKE)' not env -i, so if you export SYSROOT it should be seen. >An example of a problem boot related Makefile is >sys/boot/i386/gptboot/Makefile. Yep, and this is where CFLAGS_LAST comes in handy with CFLAGS+= ${CFLAGS_LAST} in bsd.init.mk or bsd.sys.mk From owner-freebsd-arch@FreeBSD.ORG Thu Feb 28 06:02: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 4E909277 for ; Thu, 28 Feb 2013 06:02:51 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ia0-x236.google.com (mail-ia0-x236.google.com [IPv6:2607:f8b0:4001:c02::236]) by mx1.freebsd.org (Postfix) with ESMTP id 1A59AD22 for ; Thu, 28 Feb 2013 06:02:51 +0000 (UTC) Received: by mail-ia0-f182.google.com with SMTP id k38so1216276iah.41 for ; Wed, 27 Feb 2013 22:02:50 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=xrC209zEoNypFIcAkm7gWS8jByU+3w3KtzV7C10JAmU=; b=PV0E1po6xD0C2sl5RXBvvYCfBzFUOyJyqjX+zqUTe6RufPebgtcenJDYgT9B0wlXS3 KuN5YnywYBToovOWe5ZDkX30GbcAlAWec9y6g71hBOVWn8o0ar1LLvcobQx2o4BaMVQL jZ2MAKxRbkWG0I7zxIH1aljCUdUILkTTrabKRTDuIa8r44R475h2Ezg6RdbnFnucdwrV zkQCCNsM810lxmrwKCsU36CWRBBe7kwirLETiET1XcnX0Kjvhmp4iDJU3a4bYA/PQSwd q+grrD4YAtdgcP6UPpaA4AKpd3xl23g4Kzo/1p8aGpHhtFZ+mCrDR3S+ff/TpRrZj9+V kO6Q== X-Received: by 10.50.155.168 with SMTP id vx8mr9329188igb.73.1362031370077; Wed, 27 Feb 2013 22:02:50 -0800 (PST) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id xe9sm8676369igb.7.2013.02.27.22.02.47 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Feb 2013 22:02:48 -0800 (PST) Sender: Warner Losh Subject: Re: [RFC] external compiler support Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20130228000241.GF19594@lor.one-eyed-alien.net> Date: Wed, 27 Feb 2013 23:02:46 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130227003517.GB7348@lor.one-eyed-alien.net> <28404C12-67F3-44F0-AB28-02B749472873@bsdimp.com> <51BB3E17-128A-4989-B272-D8B40D4B854B@bsdimp.com> <20130227190804.GB17489@lor.one-eyed-alien.net> <13FB8CB0-9937-4BD8-AE89-0D24494D8663@bsdimp.com> <20130227214445.GA19594@lor.one-eyed-alien.net> <1CC1DB5A-E87A-456C-AD2C-E203146BB736@bsdimp.com> <20130227221552.GC19594@lor.one-eyed-alien.net> <20130228000241.GF19594@lor.one-eyed-alien.net> To: Brooks Davis X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQk1g0GZKAtTithGyVhzPHX/MRlPgK1rAEDDnjetrYxY/eyfwSpLIGd+1gUq7NlDlmrEXBER 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: Thu, 28 Feb 2013 06:02:51 -0000 On Feb 27, 2013, at 5:02 PM, Brooks Davis wrote: > On Wed, Feb 27, 2013 at 04:15:52PM -0600, Brooks Davis wrote: >> On Wed, Feb 27, 2013 at 02:47:59PM -0700, Warner Losh wrote: >>>=20 >>> On Feb 27, 2013, at 2:44 PM, Brooks Davis wrote: >>>>>> As a strawman, let's say we add a CROSS_COMPILER_PATH and a >>>>>> CROSS_BINUTILS_PATH. The former will set XCC, XCXX, and XCPP if = they >>>>>> are unset. The latter will control -B and set the various = binutils >>>>>> variables (XNM, XLD, etc). >>>>>=20 >>>>> I'm not sure I like splitting things like that. It is unnatural. >>>>=20 >>>> That's the traditional view with lots of historic merit. At least = in >>>> the short term it's not a useful view for me. I want to be able to >>>> use our existing infrastructure to build a cross binutils and then = use >>>> it with an external compiler. In a clang world, we currently have = one >>>> compiler and many binutils unless we gratuitously build many = compilers >>>> as the FreeBSD build system currently does. Some day we will = likely have >>>> an all-llvm toolchain available and then we will have one toolchain = for >>>> all supported architectures. >>>>=20 >>>> I suppose could hack what I want to do into the traditional single >>>> toolchain world view by build a mips64 xdev toolchain and then = building >>>> a linkfarm and/or set of wrapper scripts to it and the clang I want = to >>>> include, but that seems problematic from a reproducability = perspective >>>> (not to mention performance if I need wrappers to set -B). >>>>=20 >>>> Having a CROSS_TOOLCHAIN_PATH path that sets both would probably be = a >>>> useful compromise in this regard. >>>=20 >>> Are you suggesting something like: >>>=20 >>> CROSS_COMPILER_PATH?=3D${CROSS_TOOLCHAIN_PATH} >>> CROSS_BINUTILS_PATH?=3D${CROSS_TOOLCHAIN_PATH} >>>=20 >>> If so, I'd agree, that would be a very useful compromise: hits my = ease of use issues, and lets you do what you need on the theory that = others will likely need it too. >>=20 >> That's exactly what I'm thinking. >=20 > Here's a rework with that implemented. I'm not 100% sure I got the = list > of binutils right, but it notionally supports both my usecase and a = more > classic cross compiler set. >=20 > -- Brooks >=20 > MFP4 222356, 222371, 222375, 222391, 222403, 222407, 222411, 222446 >=20 > Add support for an external cross compiler. The cross compiler is > specified by passing the XCC, XCXX, and XCPP variables (corresponding = to > CC, CXX, and CPP) to buildworld/buildkernel. The compiler must be = clang > or be configured to target the appropriate architecture. >=20 > To speed build times, if XCC is an absolute path or > WITHOUT_CROSS_COMPILER is defined then no cross compiler will be built > during the cross-tools stage. >=20 > To facilitate the use of unmodified external compilers, a > WITHOUT_FORMAT_EXTENSIONS option is available to supress printf format > checking. >=20 > As a short-term measure, supress a few new clang warnings during = kernel > builds. >=20 > Sponsored by: DARPA, AFRL > Reviewed by: xxx Looks a lot better, some minor comments.. > --- ../../freebsd/src/Makefile.inc1 2013-02-26 21:31:09.000000000 = +0000 > +++ ./Makefile.inc1 2013-02-27 23:31:46.000000000 +0000 > @@ -280,15 +280,61 @@ > .if ${MK_CDDL} =3D=3D "no" > WMAKEENV+=3D NO_CTF=3D1 > .endif > -.if ${CC:T:Mgcc} =3D=3D "gcc" > + > +.if defined(CROSS_TOOLCHAIN_PATH) > +CROSS_COMPILER_PATH?=3D${CROSS_TOOLCHAIN_PATH} > +CROSS_BINUTILS_PATH?=3D${CROSS_TOOLCHAIN_PATH} > +.endif > +XCOMPILERS=3D CC CXX CPP > +.for COMPILER in ${XCOMPILERS} > +.if defined(CROSS_COMPILER_PATH) > +X${COMPILER}?=3D ${CROSS_COMPILER_PATH}/${${COMPILER}} This makes it harder to support FreeBSD make xdev-built compilers. Can = you lose the / and require it to be specified if someone wants to use = just a path? > +.else > +X${COMPILER}?=3D ${${COMPILER}} > +.endif > +.endfor > +XBINUTILS=3D AS AR LD NM OBJDUMP RANLIB STRINGS > +.for BINUTIL in ${XBINUTILS} > +.if defined(CROSS_BINUTILS_PATH) > +X${BINUTIL}?=3D ${CROSS_BINUTILS_PATH}/${${BINUTIL}} Same. > +.else > +X${BINUTIL}?=3D ${${BINUTIL}} > +.endif > +.endfor > +WMAKEENV+=3D CC=3D"${XCC} ${XFLAGS}" CXX=3D"${XCXX} ${XFLAGS}" \ > + CPP=3D"${XCPP} ${XFLAGS}" \ > + AS=3D"${XAS}" AR=3D"${XAR}" LD=3D"${XLD}" NM=3D${XNM} \ > + OBJDUMP=3D${XOBJDUMP} RANLIB=3D${RANLIB} = STRINGS=3D${XSTRINGS} XRANLIB maybe? > + > +.if ${XCC:T:Mgcc} =3D=3D "gcc" > WMAKE_COMPILER_TYPE=3D gcc > -.elif ${CC:T:Mclang} =3D=3D "clang" > +.elif ${XCC:T:Mclang} =3D=3D "clang" > WMAKE_COMPILER_TYPE=3D clang > .elif ${MK_CLANG_IS_CC} =3D=3D "no" > WMAKE_COMPILER_TYPE=3D gcc > .else > WMAKE_COMPILER_TYPE=3D clang > .endif > + > +.if ${XCC:M/*} > +XFLAGS=3D --sysroot=3D${WORLDTMP} > +.if defined(CROSS_BINUTILS_PATH) > +XFLAGS+=3D -B${CROSS_BINUTILS_PATH} Hmmm, but this would need to change somehow... > +.else > +XFLAGS+=3D -B${WORLDTMP}/usr/bin > +.endif > +.if ${TARGET_ARCH} !=3D ${MACHINE_ARCH} && ${WMAKE_COMPILER_TYPE} =3D=3D= "clang" > +.if (${TARGET_ARCH} =3D=3D "arm" || ${TARGET_ARCH} =3D=3D "armv6") && = \ > +${MK_ARM_EABI} !=3D "no" > +TARGET_ABI=3D gnueabi > +.else > +TARGET_ABI=3D unknown > +.endif > +TARGET_TRIPLE?=3D = ${TARGET_ARCH:C/amd64/x86_64/}-${TARGET_ABI}-freebsd10.0 > +XFLAGS+=3D -target ${TARGET_TRIPLE} > +.endif > +.endif > + > WMAKEENV+=3D COMPILER_TYPE=3D${WMAKE_COMPILER_TYPE} > WMAKE=3D ${WMAKEENV} ${MAKE} ${WORLD_FLAGS} -f = Makefile.inc1 DESTDIR=3D${WORLDTMP} >=20 > @@ -321,6 +367,7 @@ >=20 >=20 > LIB32FLAGS=3D -m32 ${LIB32CPUFLAGS} -DCOMPAT_32BIT \ > + --sysroot=3D${WORLDTMP} \ > -isystem ${LIB32TMP}/usr/include/ \ > -L${LIB32TMP}/usr/lib32 \ > -B${LIB32TMP}/usr/lib32 > @@ -336,8 +383,8 @@ > SHLIBDIR=3D/usr/lib32 \ > COMPILER_TYPE=3D${WMAKE_COMPILER_TYPE} > LIB32WMAKEFLAGS+=3D \ > - CC=3D"${CC} ${LIB32FLAGS}" \ > - CXX=3D"${CXX} ${LIB32FLAGS}" \ > + CC=3D"${XCC} ${LIB32FLAGS}" \ > + CXX=3D"${XCXX} ${LIB32FLAGS}" \ > DESTDIR=3D${LIB32TMP} \ > -DCOMPAT_32BIT \ > -DLIBRARIES_ONLY \ > @@ -1284,10 +1331,13 @@ > .endif > .endif >=20 > -.if ${MK_BINUTILS} !=3D "no" > +.if ${XAS:M/*} =3D=3D "" && ${MK_BINUTILS} !=3D "no" > _binutils=3D gnu/usr.bin/binutils > .endif >=20 > +# If an full path to an external cross compiler is given, don't build > +# a cross compiler. > +.if ${XCC:M/*} =3D=3D "" && ${MK_CROSS_COMPILER} !=3D "no" > .if ${MK_CLANG} !=3D "no" && (${MK_CLANG_IS_CC} !=3D "no" || = ${CC:T:Mclang} =3D=3D "clang") > _clang=3D usr.bin/clang > _clang_libs=3D lib/clang > @@ -1296,6 +1346,7 @@ > .if ${MK_GCC} !=3D "no" && (${MK_CLANG_IS_CC} =3D=3D "no" || ${TARGET} = =3D=3D "pc98") > _cc=3D gnu/usr.bin/cc > .endif > +.endif >=20 > cross-tools: > .for _tool in \ > --- ../../freebsd/src/share/mk/bsd.own.mk 2013-02-15 = 18:49:13.000000000 +0000 > +++ share/mk/bsd.own.mk 2013-02-26 21:10:50.000000000 +0000 > @@ -262,6 +262,7 @@ > CAPSICUM \ > CDDL \ > CPP \ > + CROSS_COMPILER \ > CRYPT \ > CTM \ > CVS \ > @@ -271,6 +272,7 @@ > ED_CRYPTO \ > EXAMPLES \ > FLOPPY \ > + FORMAT_EXTENSIONS \ > FORTH \ > FP_LIBC \ > FREEBSD_UPDATE \ > --- ../../freebsd/src/sys/conf/kern.mk 2012-11-11 = 22:15:16.000000000 +0000 > +++ sys/conf/kern.mk 2013-02-26 20:35:48.000000000 +0000 > @@ -5,7 +5,7 @@ > # > CWARNFLAGS?=3D -Wall -Wredundant-decls -Wnested-externs = -Wstrict-prototypes \ > -Wmissing-prototypes -Wpointer-arith -Winline = -Wcast-qual \ > - -Wundef -Wno-pointer-sign -fformat-extensions \ > + -Wundef -Wno-pointer-sign ${FORMAT_EXTENTIONS} \ > -Wmissing-include-dirs -fdiagnostics-show-option \ > ${CWARNEXTRA} > # > @@ -29,7 +29,18 @@ > # enough to error out the whole kernel build. Display them anyway, so = there is > # some incentive to fix them eventually. > CWARNEXTRA?=3D -Wno-error-tautological-compare = -Wno-error-empty-body \ > - -Wno-error-parentheses-equality > + -Wno-error-parentheses-equality \ > + -Wno-sizeof-pointer-memaccess \ > + -Wno-unused-command-line-argument \ > + ${NO_WFORMAT} > +.endif > + > +# External compilers may not support our format extensions. Allow = them > +# to be disabled. WARNING: format checking is disabled in this case. > +.if ${MK_FORMAT_EXTENSIONS} =3D=3D "no" > +NO_WFORMAT=3D -Wno-format > +.else > +FORMAT_EXTENTIONS=3D -fformat-extensions > .endif >=20 > # > diff -uN ../../freebsd/src/tools/build/options/WITHOUT_CROSS_COMPILER = tools/build/options/WITHOUT_CROSS_COMPILER > --- ../../freebsd/src/tools/build/options/WITHOUT_CROSS_COMPILER = 1970-01-01 00:00:00.000000000 +0000 > +++ tools/build/options/WITHOUT_CROSS_COMPILER 2013-02-26 = 21:10:50.000000000 +0000 > @@ -0,0 +1,3 @@ > +.\" $FreeBSD$ > +Set to not build a cross compiler in the cross-tools stage of > +buildworld, buildkernel, etc. > diff -uN = ../../freebsd/src/tools/build/options/WITHOUT_FORMAT_EXTENSIONS = tools/build/options/WITHOUT_FORMAT_EXTENSIONS > --- ../../freebsd/src/tools/build/options/WITHOUT_FORMAT_EXTENSIONS = 1970-01-01 00:00:00.000000000 +0000 > +++ tools/build/options/WITHOUT_FORMAT_EXTENSIONS 2013-02-26 = 20:35:48.000000000 +0000 > @@ -0,0 +1,5 @@ > +.\" $FreeBSD$ > +Set to not enable > +.Fl fformat-extensions > +when compiling the kernel. > +Also disables all format checking. From owner-freebsd-arch@FreeBSD.ORG Thu Feb 28 17:19:54 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 CCBE6648 for ; Thu, 28 Feb 2013 17:19:54 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) by mx1.freebsd.org (Postfix) with ESMTP id 768EE344 for ; Thu, 28 Feb 2013 17:19:53 +0000 (UTC) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.5/8.14.5) with ESMTP id r1SHJm3b033095; Thu, 28 Feb 2013 11:19:48 -0600 (CST) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.5/8.14.5/Submit) id r1SHJlOL033094; Thu, 28 Feb 2013 11:19:47 -0600 (CST) (envelope-from brooks) Date: Thu, 28 Feb 2013 11:19:47 -0600 From: Brooks Davis To: "Simon J. Gerraty" Subject: Re: [RFC] external compiler support Message-ID: <20130228171947.GA20864@lor.one-eyed-alien.net> References: <20130227003517.GB7348@lor.one-eyed-alien.net> <28404C12-67F3-44F0-AB28-02B749472873@bsdimp.com> <51BB3E17-128A-4989-B272-D8B40D4B854B@bsdimp.com> <20130227175006.A604A58096@chaos.jnpr.net> <20130227195807.GA19255@lor.one-eyed-alien.net> <20130227202822.8F53B58096@chaos.jnpr.net> <20130227220520.GB19594@lor.one-eyed-alien.net> <20130227232632.74C2F58096@chaos.jnpr.net> <20130227235952.GE19594@lor.one-eyed-alien.net> <20130228013915.DF81E58096@chaos.jnpr.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="azLHFNyN32YCQGCU" Content-Disposition: inline In-Reply-To: <20130228013915.DF81E58096@chaos.jnpr.net> 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: Thu, 28 Feb 2013 17:19:54 -0000 --azLHFNyN32YCQGCU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 27, 2013 at 05:39:15PM -0800, Simon J. Gerraty wrote: >=20 > On Wed, 27 Feb 2013 17:59:52 -0600, Brooks Davis writes: > >> CFLAGS_LAST.clang +=3D3D -isystem ${STAGE_OBJTOP}/usr/include/clang/3.2 > >> CXXFLAGS_LAST +=3D3D ${CFLAGS_LAST.${COMPILER_TYPE}} > > > >Hmm, I've not had to do that, but it seems likely that similar things > >could be required. >=20 > I was even more suprised to find that clang needed=20 >=20 > -isystem ${STAGE_OBJTOP}/usr/include/c++/${GCCVER:U4.2} >=20 > .meta files are great for finding out what the compiler is really doing ;= -) I'm curious, is there a way to log failed fail accesses in metamode? I know clang does a fair bit of probing for things like binutils bits and I believe it does the same with headers. This could lead to some interesting surprises. > Of course all these -isystem's are needed because I use -nostdinc to > avoid accidentally pulling headers from /usr/include. > With sysroot support that wouldn't be necessary. Ah, I see. The only thing I know of that currently stops the base system compiler from being used with --sysroot is that ld doesn't support it unless it's compiled with a sysroot. This seems inane to me. I've been tempted for a while to compile it with a default sysroot of "/" to enable sysroot support. > >I think remember the issue now. The problem was that I was setting a > >variable (SYSROOT) that would cause additions to CFLAGS. Because the > >crunch environment is set by crunchgen I wasn't able to figure out a good >=20 > looks like crunchgen uses 'env MAKEOBJDIRPREFIX=3D$(MAKEOBJDIRPREFIX) $(M= AKE)' > not env -i, so if you export SYSROOT it should be seen. >=20 > >An example of a problem boot related Makefile is > >sys/boot/i386/gptboot/Makefile. >=20 > Yep, and this is where CFLAGS_LAST comes in handy with=20 >=20 > CFLAGS+=3D ${CFLAGS_LAST} >=20 > in bsd.init.mk or bsd.sys.mk OK, that makes sense and should work. I think I'm inclined to go with my current approach for now and then migrate to what ever form of ${CFLAGS_LAST} and friends that we end up with after we've debated the issues there and decided how much abstraction we really want. -- Brooks --azLHFNyN32YCQGCU Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iD8DBQFRL5GzXY6L6fI4GtQRAsaBAJ0fPJDfhE/lXkp132e+qnhM2hAMXQCghEsE kGPaYBPAeE7ePcYk6ZeoRKQ= =n3YK -----END PGP SIGNATURE----- --azLHFNyN32YCQGCU-- From owner-freebsd-arch@FreeBSD.ORG Thu Feb 28 17:23:23 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 97E9A78B for ; Thu, 28 Feb 2013 17:23:23 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) by mx1.freebsd.org (Postfix) with ESMTP id 37E49384 for ; Thu, 28 Feb 2013 17:23:19 +0000 (UTC) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.5/8.14.5) with ESMTP id r1SHNJgo033133; Thu, 28 Feb 2013 11:23:19 -0600 (CST) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.5/8.14.5/Submit) id r1SHNIeX033132; Thu, 28 Feb 2013 11:23:18 -0600 (CST) (envelope-from brooks) Date: Thu, 28 Feb 2013 11:23:18 -0600 From: Brooks Davis To: Warner Losh Subject: Re: [RFC] external compiler support Message-ID: <20130228172318.GB20864@lor.one-eyed-alien.net> References: <20130227003517.GB7348@lor.one-eyed-alien.net> <28404C12-67F3-44F0-AB28-02B749472873@bsdimp.com> <51BB3E17-128A-4989-B272-D8B40D4B854B@bsdimp.com> <20130227190804.GB17489@lor.one-eyed-alien.net> <13FB8CB0-9937-4BD8-AE89-0D24494D8663@bsdimp.com> <20130227214445.GA19594@lor.one-eyed-alien.net> <1CC1DB5A-E87A-456C-AD2C-E203146BB736@bsdimp.com> <20130227221552.GC19594@lor.one-eyed-alien.net> <20130228000241.GF19594@lor.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="QTprm0S8XgL7H0Dt" Content-Disposition: inline In-Reply-To: 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: Thu, 28 Feb 2013 17:23:23 -0000 --QTprm0S8XgL7H0Dt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 27, 2013 at 11:02:46PM -0700, Warner Losh wrote: >=20 > On Feb 27, 2013, at 5:02 PM, Brooks Davis wrote: >=20 > > On Wed, Feb 27, 2013 at 04:15:52PM -0600, Brooks Davis wrote: > >> On Wed, Feb 27, 2013 at 02:47:59PM -0700, Warner Losh wrote: > >>>=20 > >>> On Feb 27, 2013, at 2:44 PM, Brooks Davis wrote: > >>>>>> As a strawman, let's say we add a CROSS_COMPILER_PATH and a > >>>>>> CROSS_BINUTILS_PATH. The former will set XCC, XCXX, and XCPP if t= hey > >>>>>> are unset. The latter will control -B and set the various binutils > >>>>>> variables (XNM, XLD, etc). > >>>>>=20 > >>>>> I'm not sure I like splitting things like that. It is unnatural. > >>>>=20 > >>>> That's the traditional view with lots of historic merit. At least in > >>>> the short term it's not a useful view for me. I want to be able to > >>>> use our existing infrastructure to build a cross binutils and then u= se > >>>> it with an external compiler. In a clang world, we currently have o= ne > >>>> compiler and many binutils unless we gratuitously build many compile= rs > >>>> as the FreeBSD build system currently does. Some day we will likely= have > >>>> an all-llvm toolchain available and then we will have one toolchain = for > >>>> all supported architectures. > >>>>=20 > >>>> I suppose could hack what I want to do into the traditional single > >>>> toolchain world view by build a mips64 xdev toolchain and then build= ing > >>>> a linkfarm and/or set of wrapper scripts to it and the clang I want = to > >>>> include, but that seems problematic from a reproducability perspecti= ve > >>>> (not to mention performance if I need wrappers to set -B). > >>>>=20 > >>>> Having a CROSS_TOOLCHAIN_PATH path that sets both would probably be a > >>>> useful compromise in this regard. > >>>=20 > >>> Are you suggesting something like: > >>>=20 > >>> CROSS_COMPILER_PATH?=3D${CROSS_TOOLCHAIN_PATH} > >>> CROSS_BINUTILS_PATH?=3D${CROSS_TOOLCHAIN_PATH} > >>>=20 > >>> If so, I'd agree, that would be a very useful compromise: hits my eas= e of use issues, and lets you do what you need on the theory that others wi= ll likely need it too. > >>=20 > >> That's exactly what I'm thinking. > >=20 > > Here's a rework with that implemented. I'm not 100% sure I got the list > > of binutils right, but it notionally supports both my usecase and a more > > classic cross compiler set. > >=20 > > -- Brooks > >=20 > > MFP4 222356, 222371, 222375, 222391, 222403, 222407, 222411, 222446 > >=20 > > Add support for an external cross compiler. The cross compiler is > > specified by passing the XCC, XCXX, and XCPP variables (corresponding to > > CC, CXX, and CPP) to buildworld/buildkernel. The compiler must be clang > > or be configured to target the appropriate architecture. > >=20 > > To speed build times, if XCC is an absolute path or > > WITHOUT_CROSS_COMPILER is defined then no cross compiler will be built > > during the cross-tools stage. > >=20 > > To facilitate the use of unmodified external compilers, a > > WITHOUT_FORMAT_EXTENSIONS option is available to supress printf format > > checking. > >=20 > > As a short-term measure, supress a few new clang warnings during kernel > > builds. > >=20 > > Sponsored by: DARPA, AFRL > > Reviewed by: xxx >=20 > Looks a lot better, some minor comments.. Here's another version that addresses those comments. I decided to rename CROSS_*_PATH to CROSS_*_PREFIX because it offended my sensibilities to call something that may not refer to a filesystem object a path. -- Brooks MFP4 222356, 222371, 222375, 222391, 222403, 222407, 222411, 222446, 222461 Add support for an external cross compiler. The cross compiler is specified by passing the XCC, XCXX, and XCPP variables (corresponding to CC, CXX, and CPP) to buildworld/buildkernel. The compiler must be clang or be configured to target the appropriate architecture. To speed build times, if XCC is an absolute path or WITHOUT_CROSS_COMPILER is defined then no cross compiler will be built during the cross-tools stage. To facilitate the use of unmodified external compilers, a WITHOUT_FORMAT_EXTENSIONS option is available to supress printf format checking. As a short-term measure, supress a few new clang warnings during kernel builds. Sponsored by: DARPA, AFRL Reviewed by: xxx --- ../../freebsd/src/Makefile.inc1 2013-02-26 21:31:09.000000000 +0000 +++ ./Makefile.inc1 2013-02-28 16:44:30.000000000 +0000 @@ -280,15 +280,66 @@ .if ${MK_CDDL} =3D=3D "no" WMAKEENV+=3D NO_CTF=3D1 .endif -.if ${CC:T:Mgcc} =3D=3D "gcc" + +.if defined(CROSS_TOOLCHAIN_PREFIX) +CROSS_COMPILER_PREFIX?=3D${CROSS_TOOLCHAIN_PREFIX} +CROSS_BINUTILS_PREFIX?=3D${CROSS_TOOLCHAIN_PREFIX} +.endif +XCOMPILERS=3D CC CXX CPP +.for COMPILER in ${XCOMPILERS} +.if defined(CROSS_COMPILER_PREFIX) +X${COMPILER}?=3D ${CROSS_COMPILER_PREFIX}${${COMPILER}} +.else +X${COMPILER}?=3D ${${COMPILER}} +.endif +.endfor +XBINUTILS=3D AS AR LD NM OBJDUMP RANLIB STRINGS +.for BINUTIL in ${XBINUTILS} +.if defined(CROSS_BINUTILS_PREFIX) +X${BINUTIL}?=3D ${CROSS_BINUTILS_PREFIX}${${BINUTIL}} +.else +X${BINUTIL}?=3D ${${BINUTIL}} +.endif +.endfor +WMAKEENV+=3D CC=3D"${XCC} ${XFLAGS}" CXX=3D"${XCXX} ${XFLAGS}" \ + CPP=3D"${XCPP} ${XFLAGS}" \ + AS=3D"${XAS}" AR=3D"${XAR}" LD=3D"${XLD}" NM=3D${XNM} \ + OBJDUMP=3D${XOBJDUMP} RANLIB=3D${XRANLIB} STRINGS=3D${XSTRINGS} + +.if ${XCC:T:Mgcc} =3D=3D "gcc" WMAKE_COMPILER_TYPE=3D gcc -.elif ${CC:T:Mclang} =3D=3D "clang" +.elif ${XCC:T:Mclang} =3D=3D "clang" WMAKE_COMPILER_TYPE=3D clang .elif ${MK_CLANG_IS_CC} =3D=3D "no" WMAKE_COMPILER_TYPE=3D gcc .else WMAKE_COMPILER_TYPE=3D clang .endif + +.if ${XCC:M/*} +XFLAGS=3D --sysroot=3D${WORLDTMP} +.if defined(CROSS_BINUTILS_PREFIX) +# In the case of xdev-build tools, CROSS_BINUTILS_PREFIX won't be a +# directory, but the compiler will look in the right place for it's +# tools so we don't need to tell it where to look. +.if exists(${CROSS_BINUTILS_PREFIX}) +XFLAGS+=3D -B${CROSS_BINUTILS_PREFIX} +.endif +.else +XFLAGS+=3D -B${WORLDTMP}/usr/bin +.endif +.if ${TARGET_ARCH} !=3D ${MACHINE_ARCH} && ${WMAKE_COMPILER_TYPE} =3D=3D "= clang" +.if (${TARGET_ARCH} =3D=3D "arm" || ${TARGET_ARCH} =3D=3D "armv6") && \ +${MK_ARM_EABI} !=3D "no" +TARGET_ABI=3D gnueabi +.else +TARGET_ABI=3D unknown +.endif +TARGET_TRIPLE?=3D ${TARGET_ARCH:C/amd64/x86_64/}-${TARGET_ABI}-freebsd10.0 +XFLAGS+=3D -target ${TARGET_TRIPLE} +.endif +.endif + WMAKEENV+=3D COMPILER_TYPE=3D${WMAKE_COMPILER_TYPE} WMAKE=3D ${WMAKEENV} ${MAKE} ${WORLD_FLAGS} -f Makefile.inc1 DESTDIR=3D${= WORLDTMP} =20 @@ -321,6 +372,7 @@ =20 =20 LIB32FLAGS=3D -m32 ${LIB32CPUFLAGS} -DCOMPAT_32BIT \ + --sysroot=3D${WORLDTMP} \ -isystem ${LIB32TMP}/usr/include/ \ -L${LIB32TMP}/usr/lib32 \ -B${LIB32TMP}/usr/lib32 @@ -336,8 +388,8 @@ SHLIBDIR=3D/usr/lib32 \ COMPILER_TYPE=3D${WMAKE_COMPILER_TYPE} LIB32WMAKEFLAGS+=3D \ - CC=3D"${CC} ${LIB32FLAGS}" \ - CXX=3D"${CXX} ${LIB32FLAGS}" \ + CC=3D"${XCC} ${LIB32FLAGS}" \ + CXX=3D"${XCXX} ${LIB32FLAGS}" \ DESTDIR=3D${LIB32TMP} \ -DCOMPAT_32BIT \ -DLIBRARIES_ONLY \ @@ -1284,10 +1336,13 @@ .endif .endif =20 -.if ${MK_BINUTILS} !=3D "no" +.if ${XAS:M/*} =3D=3D "" && ${MK_BINUTILS} !=3D "no" _binutils=3D gnu/usr.bin/binutils .endif =20 +# If an full path to an external cross compiler is given, don't build +# a cross compiler. +.if ${XCC:M/*} =3D=3D "" && ${MK_CROSS_COMPILER} !=3D "no" .if ${MK_CLANG} !=3D "no" && (${MK_CLANG_IS_CC} !=3D "no" || ${CC:T:Mclang= } =3D=3D "clang") _clang=3D usr.bin/clang _clang_libs=3D lib/clang @@ -1296,6 +1351,7 @@ .if ${MK_GCC} !=3D "no" && (${MK_CLANG_IS_CC} =3D=3D "no" || ${TARGET} =3D= =3D "pc98") _cc=3D gnu/usr.bin/cc .endif +.endif =20 cross-tools: .for _tool in \ --- ../../freebsd/src/share/mk/bsd.own.mk 2013-02-15 18:49:13.000000000 +00= 00 +++ share/mk/bsd.own.mk 2013-02-26 21:10:50.000000000 +0000 @@ -262,6 +262,7 @@ CAPSICUM \ CDDL \ CPP \ + CROSS_COMPILER \ CRYPT \ CTM \ CVS \ @@ -271,6 +272,7 @@ ED_CRYPTO \ EXAMPLES \ FLOPPY \ + FORMAT_EXTENSIONS \ FORTH \ FP_LIBC \ FREEBSD_UPDATE \ --- ../../freebsd/src/sys/conf/kern.mk 2012-11-11 22:15:16.000000000 +0000 +++ sys/conf/kern.mk 2013-02-26 20:35:48.000000000 +0000 @@ -5,7 +5,7 @@ # CWARNFLAGS?=3D -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototype= s \ -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual \ - -Wundef -Wno-pointer-sign -fformat-extensions \ + -Wundef -Wno-pointer-sign ${FORMAT_EXTENTIONS} \ -Wmissing-include-dirs -fdiagnostics-show-option \ ${CWARNEXTRA} # @@ -29,7 +29,18 @@ # enough to error out the whole kernel build. Display them anyway, so the= re is # some incentive to fix them eventually. CWARNEXTRA?=3D -Wno-error-tautological-compare -Wno-error-empty-body \ - -Wno-error-parentheses-equality + -Wno-error-parentheses-equality \ + -Wno-sizeof-pointer-memaccess \ + -Wno-unused-command-line-argument \ + ${NO_WFORMAT} +.endif + +# External compilers may not support our format extensions. Allow them +# to be disabled. WARNING: format checking is disabled in this case. +.if ${MK_FORMAT_EXTENSIONS} =3D=3D "no" +NO_WFORMAT=3D -Wno-format +.else +FORMAT_EXTENTIONS=3D -fformat-extensions .endif =20 # diff -uN ../../freebsd/src/tools/build/options/WITHOUT_CROSS_COMPILER tools= /build/options/WITHOUT_CROSS_COMPILER --- ../../freebsd/src/tools/build/options/WITHOUT_CROSS_COMPILER 1970-01-01= 00:00:00.000000000 +0000 +++ tools/build/options/WITHOUT_CROSS_COMPILER 2013-02-26 21:10:50.00000000= 0 +0000 @@ -0,0 +1,3 @@ +.\" $FreeBSD$ +Set to not build a cross compiler in the cross-tools stage of +buildworld, buildkernel, etc. diff -uN ../../freebsd/src/tools/build/options/WITHOUT_FORMAT_EXTENSIONS to= ols/build/options/WITHOUT_FORMAT_EXTENSIONS --- ../../freebsd/src/tools/build/options/WITHOUT_FORMAT_EXTENSIONS 1970-01= -01 00:00:00.000000000 +0000 +++ tools/build/options/WITHOUT_FORMAT_EXTENSIONS 2013-02-26 20:35:48.00000= 0000 +0000 @@ -0,0 +1,5 @@ +.\" $FreeBSD$ +Set to not enable +.Fl fformat-extensions +when compiling the kernel. +Also disables all format checking. --QTprm0S8XgL7H0Dt Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iD8DBQFRL5KGXY6L6fI4GtQRAle4AKCbHWlkXozVQxHwiX8sc/SD8YG73QCfWYHd fnDDmsstIOciqvREFr38OtQ= =MDSJ -----END PGP SIGNATURE----- --QTprm0S8XgL7H0Dt-- From owner-freebsd-arch@FreeBSD.ORG Thu Feb 28 21:59:19 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 DD7F4C44; Thu, 28 Feb 2013 21:59:19 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by mx1.freebsd.org (Postfix) with ESMTP id 70271651; Thu, 28 Feb 2013 21:59:19 +0000 (UTC) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKUS/TMPXUYwLp1YQowlF8YZrclo8C3GLK@postini.com; Thu, 28 Feb 2013 13:59:19 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 28 Feb 2013 13:53:42 -0800 Received: from chaos.jnpr.net (chaos.jnpr.net [172.24.29.229]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id r1SLrg340733; Thu, 28 Feb 2013 13:53:42 -0800 (PST) (envelope-from sjg@juniper.net) Received: from chaos.jnpr.net (localhost [127.0.0.1]) by chaos.jnpr.net (Postfix) with ESMTP id D9DA758096; Thu, 28 Feb 2013 13:53:41 -0800 (PST) To: Brooks Davis Subject: Re: [RFC] external compiler support In-Reply-To: <20130228171947.GA20864@lor.one-eyed-alien.net> References: <20130227003517.GB7348@lor.one-eyed-alien.net> <28404C12-67F3-44F0-AB28-02B749472873@bsdimp.com> <51BB3E17-128A-4989-B272-D8B40D4B854B@bsdimp.com> <20130227175006.A604A58096@chaos.jnpr.net> <20130227195807.GA19255@lor.one-eyed-alien.net> <20130227202822.8F53B58096@chaos.jnpr.net> <20130227220520.GB19594@lor.one-eyed-alien.net> <20130227232632.74C2F58096@chaos.jnpr.net> <20130227235952.GE19594@lor.one-eyed-alien.net> <20130228013915.DF81E58096@chaos.jnpr.net> <20130228171947.GA20864@lor.one-eyed-alien.net> Comments: In-reply-to: Brooks Davis message dated "Thu, 28 Feb 2013 11:19:47 -0600." From: "Simon J. Gerraty" X-Mailer: MH-E 7.82+cvs; nmh 1.3; GNU Emacs 22.3.1 Date: Thu, 28 Feb 2013 13:53:41 -0800 Message-ID: <20130228215341.D9DA758096@chaos.jnpr.net> MIME-Version: 1.0 Content-Type: text/plain 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: Thu, 28 Feb 2013 21:59:19 -0000 On Thu, 28 Feb 2013 11:19:47 -0600, Brooks Davis writes: >> .meta files are great for finding out what the compiler is really doing ;= >-) > >I'm curious, is there a way to log failed fail accesses in metamode? I No, we deliberatly only log the successful syscalls - since those are the only ones relevant to make. You can run the compiler under ktrace to see all the failed searches. >Ah, I see. The only thing I know of that currently stops the base >system compiler from being used with --sysroot is that ld doesn't >support it unless it's compiled with a sysroot. This seems inane to me. >I've been tempted for a while to compile it with a default sysroot of >"/" to enable sysroot support. That would be good. >OK, that makes sense and should work. I think I'm inclined to go with >my current approach for now and then migrate to what ever form of >${CFLAGS_LAST} and friends that we end up with after we've debated the >issues there and decided how much abstraction we really want. Sure. From owner-freebsd-arch@FreeBSD.ORG Fri Mar 1 04:40:37 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 4DA1E80F for ; Fri, 1 Mar 2013 04:40:37 +0000 (UTC) (envelope-from alvinhol@ca.rr.com) Received: from hrndva-omtalb.mail.rr.com (hrndva-omtalb.mail.rr.com [71.74.56.122]) by mx1.freebsd.org (Postfix) with ESMTP id F28AE740 for ; Fri, 1 Mar 2013 04:40:36 +0000 (UTC) X-Authority-Analysis: v=2.0 cv=UN5f7Vjy c=1 sm=0 a=3jLTjMC9pScW5Sox+oEDzQ==:17 a=cEy7TFPG0FgA:10 a=05ChyHeVI94A:10 a=8nJEP1OIZ-IA:10 a=ayC55rCoAAAA:8 a=zzWpKC7PIKVJN0v9k_AA:9 a=wPNLvfGTeEIA:10 a=3jLTjMC9pScW5Sox+oEDzQ==:117 X-Cloudmark-Score: 0 X-Authenticated-User: X-Originating-IP: 142.129.146.247 Received: from [142.129.146.247] ([142.129.146.247:1130] helo=albert-yztfrpjp) by hrndva-oedge04.mail.rr.com (envelope-from ) (ecelerity 2.2.3.46 r()) with ESMTP id 91/41-20480-E3130315; Fri, 01 Mar 2013 04:40:30 +0000 Date: Thu, 28 Feb 2013 20:40:14 -0800 Message-ID: <91.41.20480.E3130315@hrndva-omtalb.mail.rr.com> From: "AL" To: "freebsd-arch" Subject: DOS X-mailer: Foxmail 5.0 [en] Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: alvinhol@ca.rr.com List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 04:40:37 -0000 Hello freebsd-arch, Does FBSD support a DOS environment ? alvinhol@ca.rr.com 2013-02-28 From owner-freebsd-arch@FreeBSD.ORG Fri Mar 1 04:55:19 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 9ADA6A32 for ; Fri, 1 Mar 2013 04:55:19 +0000 (UTC) (envelope-from cpet@sdf.org) Received: from sdf.lonestar.org (mx.sdf.org [192.94.73.19]) by mx1.freebsd.org (Postfix) with ESMTP id 51E58790 for ; Fri, 1 Mar 2013 04:55:18 +0000 (UTC) Received: from [192.168.1.64] (dsl-187-150-24-12-dyn.prod-infinitum.com.mx [187.150.24.12] (may be forged)) (authenticated (0 bits)) by sdf.lonestar.org (8.14.5/8.14.5) with ESMTP id r214svkV003118 for ; Fri, 1 Mar 2013 04:54:58 GMT Message-ID: <513034AB.4040707@sdf.org> Date: Thu, 28 Feb 2013 22:55:07 -0600 From: Chris Petrik User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: freebsd-arch@freebsd.org Subject: Re: DOS References: <91.41.20480.E3130315@hrndva-omtalb.mail.rr.com> In-Reply-To: <91.41.20480.E3130315@hrndva-omtalb.mail.rr.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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, 01 Mar 2013 04:55:19 -0000 On 02/28/2013 10:40 PM, AL wrote: > Hello freebsd-arch, > > Does FBSD support a DOS environment ? > > alvinhol@ca.rr.com > > > > 2013-02-28 > > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" You can use dosemu and possibly others to get DOS emulation From owner-freebsd-arch@FreeBSD.ORG Fri Mar 1 07:39:32 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 7601CD8F for ; Fri, 1 Mar 2013 07:39:32 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by mx1.freebsd.org (Postfix) with ESMTP id 0AB29DA6 for ; Fri, 1 Mar 2013 07:39:31 +0000 (UTC) Received: from mailout-de.gmx.net ([10.1.76.1]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0MGDc1-1U04ra22sh-00F7iG for ; Fri, 01 Mar 2013 08:34:21 +0100 Received: (qmail invoked by alias); 01 Mar 2013 07:34:16 -0000 Received: from p5B131F95.dip.t-dialin.net (EHLO rotluchs.lokal) [91.19.31.149] by mail.gmx.net (mp001) with SMTP; 01 Mar 2013 08:34:16 +0100 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX19dAgctN+Rdftz1HV30RHPTu9nvna8RJkTx6oWarb 05SAKsUtLy3Oe2 Message-ID: <513059E0.8070503@gmx.de> Date: Fri, 01 Mar 2013 08:33:52 +0100 From: Christoph Mallon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130222 Thunderbird/17.0.3 MIME-Version: 1.0 To: Warner Losh Subject: Re: Large Capsicum patch for review. References: <20130213025547.GA2025@garage.freebsd.pl> <20130213230221.GB1375@garage.freebsd.pl> <20130223221116.GR1377@garage.freebsd.pl> <5129ADC5.5040306@gmx.de> <20130224193058.GW1377@garage.freebsd.pl> <512B3E5C.2090506@gmx.de> <61FF31A0-7051-4FAE-8399-76585B1D5018@bsdimp.com> <512E8B82.5040801@gmx.de> <6DB9C19D-C8E8-4386-8D03-6D4EC1523C1D@bsdimp.com> In-Reply-To: <6DB9C19D-C8E8-4386-8D03-6D4EC1523C1D@bsdimp.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 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, 01 Mar 2013 07:39:32 -0000 On 28.02.2013 00:08, Warner Losh wrote: > On Feb 27, 2013, at 3:41 PM, Christoph Mallon wrote: >> On 25.02.2013 15:21, Warner Losh wrote: >>> On Feb 25, 2013, at 3:35 AM, Christoph Mallon wrote: >>>> On 24.02.2013 20:30, Pawel Jakub Dawidek wrote: >>>>> Nope, but I'm using some script to generate patch(1)-compatbile diff >>>>> from a perforce diff. >>>> >>>> Ugh, why is p4 still in use, if it is just a hassle and hides history? >>> >>> Because it is the only VCS that doesn't suck at merging? While git, hg and svn do a passing fair job, they all suck compared to perforce. >> >> Uh, no. >> git's and mercurial's merging logics are reliable and fast. > > You must be using a different definition of 'reilable' than I'm accustomed to. It certainly is fast, but isn't as reliable and robust and perforce. Having used both heavily in branched environments, I can state unequivocally that perforce of 2003 did a better job than mercurial does in 2013. I've had more problems with mercurial than I ever had with perforce. I really like to see an example. >From time to time I hear the statement "my VCS X does better than VCS Y, I have seen that many times.", but in the end I never got an example. Of course, there are examples for CVS and old SVN, which do not record merges at all, but I want to see a case for systems, which record merges. I have seen cases for newer SVN, but these were blatant bugs in the implementation and I really hope, they are fixed by now. If you merged and a new file was merged in, but you already had an untracked file with the same name in your working tree, then SVN silently dropped the new file, i.e. the file was not merged at all and therefore missing after the merge. This especially happend, when you first did a trial merge, then reset, which left the new files untracked in place, and did the merge again. I do not have too much experience with mercurial. I mostly use git, in particular git-svn for FreeBSD, and it works really well. >> The fact, that a merge was performed, is encoded into the structure of the history, which makes the history a directed acyclic graph, not just a simple tree. >> This information is considered when performing merges. >> Further, there is some logic to handle cherry picks. >> Another important aspect is, that you prepare merge commits (and in fact every commit) locally, so if something went wrong, which shows up during testing, you can correct it locally and then just publish the finished, correct commit. >> So commiting in general is not an open-heart surgery thing, which is great benefit. > > Sure, it is a lot better than CVS, but it is no perforce. while mercurial does let me prepare the commit(s) locally, which is a plus over perforce, > it has mismerged things too often for me Please, show one of these cases. > to not complain when you use the word 'reliable'. I do not understand this part of the sentence. Is there are negation too much/missing? >> Since svn grew recording mergeinfo (in 1.5, if I remember correctly), it works ok, too, but it is really, really slow and has some other problems. >> Before 1.5 it was pretty much the same as cvs, i.e. it recorded only the branch point. >> For repeated merges, this meant, it tried to merge again the same stuff starting at the branching point, which lead to conflicts with later changes at the same places. >> So you had to manually specify, what should be merged. > > Newer subversions are only marginally worse than mercurial from what I've done, but my recent experience has been much more slanted to mercurial than subversion, so that impression suffers from a small sample size. Subversion is plain too slow. The most extreme case, which I experienced, was git having finished a moment after I hit enter, while svn took half an hour, because even though the merge was simple, many files were involved and all the trips over the internet took their toll (Also the bug above hit. This was the point, where we switched from svn to git). Also creating and checking out/switching branches is cumbersome. It got better with the ^-notation for paths, but it still is not on par with "git branch foo" and "git checkout foo". The fact that creating a branch also creates a commit is cumbersome and inspecting merged history is poor (compare with git log --graph [optionally also add --oneline and --decorate] or hg log -G). Interestingly, there is one thing, only git gets right: git log (and many other commands) spawns a pager. Plain hg/svn log is useless, because all the history scrolls by at full speed. You end up typing hg/svn log | less all the time. Christoph From owner-freebsd-arch@FreeBSD.ORG Fri Mar 1 11:55:08 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 E4A806A8 for ; Fri, 1 Mar 2013 11:55:08 +0000 (UTC) (envelope-from lars@e-new.0x20.net) Received: from mail.0x20.net (mail.0x20.net [217.69.76.211]) by mx1.freebsd.org (Postfix) with ESMTP id A9BCD90A for ; Fri, 1 Mar 2013 11:55:07 +0000 (UTC) Received: from e-new.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.0x20.net (Postfix) with ESMTPS id F017D6A6000; Fri, 1 Mar 2013 12:55:04 +0100 (CET) Received: from e-new.0x20.net (localhost [127.0.0.1]) by e-new.0x20.net (8.14.5/8.14.5) with ESMTP id r21Bt4I5077337; Fri, 1 Mar 2013 12:55:04 +0100 (CET) (envelope-from lars@e-new.0x20.net) Received: (from lars@localhost) by e-new.0x20.net (8.14.5/8.14.5/Submit) id r21Bt4X0076737; Fri, 1 Mar 2013 12:55:04 +0100 (CET) (envelope-from lars) Date: Fri, 1 Mar 2013 12:55:04 +0100 From: Lars Engels To: Chris Petrik Subject: Re: DOS Message-ID: <20130301115504.GG98345@e-new.0x20.net> References: <91.41.20480.E3130315@hrndva-omtalb.mail.rr.com> <513034AB.4040707@sdf.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3xoW37o/FfUZJwQG" Content-Disposition: inline In-Reply-To: <513034AB.4040707@sdf.org> X-Editor: VIM - Vi IMproved 7.3 X-Operation-System: FreeBSD 8.3-RELEASE-p4 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: Fri, 01 Mar 2013 11:55:09 -0000 --3xoW37o/FfUZJwQG Content-Type: text/plain; charset=utf-8 Content-Disposition: inline On Thu, Feb 28, 2013 at 10:55:07PM -0600, Chris Petrik wrote: > On 02/28/2013 10:40 PM, AL wrote: > > Hello freebsd-arch, > > > > Does FBSD support a DOS environment ? > > > > alvinhol@ca.rr.com emulators/dosbox --3xoW37o/FfUZJwQG Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlEwlxgACgkQKc512sD3afjhdACbBlkJbS5/4KrOWxp0TiQxmYy5 BDQAnRifV54gmrXFWMKAzAQnCuCEzYwN =KXmD -----END PGP SIGNATURE----- --3xoW37o/FfUZJwQG-- From owner-freebsd-arch@FreeBSD.ORG Fri Mar 1 17:36:19 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 6D673BF3 for ; Fri, 1 Mar 2013 17:36:19 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-yh0-x22e.google.com (mail-yh0-x22e.google.com [IPv6:2607:f8b0:4002:c01::22e]) by mx1.freebsd.org (Postfix) with ESMTP id 31E2BB46 for ; Fri, 1 Mar 2013 17:36:19 +0000 (UTC) Received: by mail-yh0-f46.google.com with SMTP id q15so496015yhf.19 for ; Fri, 01 Mar 2013 09:36:18 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=eaypYdnxCXEbJPjyz2g8fN+F0AXKdQ6C1JJIN7dH9nY=; b=A8gXiXpc7Yf/Ki1hUljaNNfnOPmCHH3SgFh0mv17PpORok+vepVtNDNeUkqAFAl4XO mHnEQtCWuzxo3pCHeVHc396U0ckj2YWEhW7pcn9z+lAJJ94616JBJN5k8mUBMg1OtFE6 zH1xF3nHjhyQpzbr3hYN+YG7aQx57AIlu/kTc/bVRlG8E+fWK/g/p1w/mysgtX/l/ZiG fxbTDR35vKQlANQ1oFdKjdYkzZmA0+G2bwln11dkRdp/uaJJzRzi0a1pT91YtG5ne9Mn in+jRc5LocV+OkW5Ued9bFtIEOX5pD5R3iuwEUF6D8GlEmVTZwgAzJCnQlR4rfff2G0S /1MQ== X-Received: by 10.236.193.102 with SMTP id j66mr7736490yhn.195.1362159378778; Fri, 01 Mar 2013 09:36:18 -0800 (PST) Received: from fusionlt2834a.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPS id w7sm20057969yhj.0.2013.03.01.09.36.16 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 01 Mar 2013 09:36:17 -0800 (PST) Sender: Warner Losh Subject: Re: Large Capsicum patch for review. Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <513059E0.8070503@gmx.de> Date: Fri, 1 Mar 2013 10:36:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130213025547.GA2025@garage.freebsd.pl> <20130213230221.GB1375@garage.freebsd.pl> <20130223221116.GR1377@garage.freebsd.pl> <5129ADC5.5040306@gmx.de> <20130224193058.GW1377@garage.freebsd.pl> <512B3E5C.2090506@gmx.de> <61FF31A0-7051-4FAE-8399-76585B1D5018@bsdimp.com> <512E8B82.5040801@gmx.de> <6DB9C19D-C8E8-4386-8D03-6D4EC1523C1D@bsdimp.com> <513059E0.8070503@gmx.de> To: Christoph Mallon X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQnQK/RVmuPe+90F1OmkUonSi/dosGrKfbk9QHKjzW9hDEDS1LkOoWzQOdA9uMLxwez1yUvz 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, 01 Mar 2013 17:36:19 -0000 On Mar 1, 2013, at 12:33 AM, Christoph Mallon wrote: > On 28.02.2013 00:08, Warner Losh wrote: >> On Feb 27, 2013, at 3:41 PM, Christoph Mallon wrote: >>> On 25.02.2013 15:21, Warner Losh wrote: >>>> On Feb 25, 2013, at 3:35 AM, Christoph Mallon wrote: >>>>> On 24.02.2013 20:30, Pawel Jakub Dawidek wrote: >>>>>> Nope, but I'm using some script to generate patch(1)-compatbile = diff >>>>>> from a perforce diff. >>>>>=20 >>>>> Ugh, why is p4 still in use, if it is just a hassle and hides = history? >>>>=20 >>>> Because it is the only VCS that doesn't suck at merging? While git, = hg and svn do a passing fair job, they all suck compared to perforce. >>>=20 >>> Uh, no. >>> git's and mercurial's merging logics are reliable and fast. >>=20 >> You must be using a different definition of 'reilable' than I'm = accustomed to. It certainly is fast, but isn't as reliable and robust = and perforce. Having used both heavily in branched environments, I can = state unequivocally that perforce of 2003 did a better job than = mercurial does in 2013. I've had more problems with mercurial than I = ever had with perforce. >=20 > I really like to see an example. It is hard to provide an example when proprietary source is involved. However, some concrete examples of hg failing me: (1) Pulling a new tree with patches from a patch queue applied is not = 100% reliable. Sometimes it gets into a weird state that I have to = unwind with bruit force. (2) Create a branch. Commit changes to that branch. merge the mainline. = cherry pick changes into the mainline. merge. After several iterations = of this, the merges collide on previously merged items sometimes, but = not always. The merges to the mainline also have increasing issues, some = that it legitimately should have, others that it shouldn't. When doing = similar work with perforce I never had these problems. > =46rom time to time I hear the statement "my VCS X does better than = VCS Y, I have seen that many times.", but in the end I never got an = example. It is hard to give an example of fail when the problems are so complex. > Of course, there are examples for CVS and old SVN, which do not record = merges at all, but I want to see a case for systems, which record = merges. > I have seen cases for newer SVN, but these were blatant bugs in the = implementation and I really hope, they are fixed by now. > If you merged and a new file was merged in, but you already had an = untracked file with the same name in your working tree, then SVN = silently dropped the new file, i.e. the file was not merged at all and = therefore missing after the merge. > This especially happend, when you first did a trial merge, then reset, = which left the new files untracked in place, and did the merge again. > I do not have too much experience with mercurial. > I mostly use git, in particular git-svn for FreeBSD, and it works = really well. Yea, I have little experience with git, just taking issue with your = characterization the mercurial's branching is robust. >>> The fact, that a merge was performed, is encoded into the structure = of the history, which makes the history a directed acyclic graph, not = just a simple tree. >>> This information is considered when performing merges. >>> Further, there is some logic to handle cherry picks. >>> Another important aspect is, that you prepare merge commits (and in = fact every commit) locally, so if something went wrong, which shows up = during testing, you can correct it locally and then just publish the = finished, correct commit. >>> So commiting in general is not an open-heart surgery thing, which is = great benefit. >>=20 >> Sure, it is a lot better than CVS, but it is no perforce. while = mercurial does let me prepare the commit(s) locally, which is a plus = over perforce, >> it has mismerged things too often for me >=20 > Please, show one of these cases. Again with proprietary software, that's hard to do. You wind up with a = file that has the chunks in really weird places sometimes, usually times = when the diffs are a bit weird (meaning that hg diff computed the diff = in a way that wasn't as minimal as you'd like). >> to not complain when you use the word 'reliable'. >=20 > I do not understand this part of the sentence. > Is there are negation too much/missing? Simple language: hg branching is not reliable. It usually works, and = when it does it is great. It doesn't work 100% of the time, and when it = fails the fails can require a lot of digging out. >>> Since svn grew recording mergeinfo (in 1.5, if I remember = correctly), it works ok, too, but it is really, really slow and has some = other problems. >>> Before 1.5 it was pretty much the same as cvs, i.e. it recorded only = the branch point. >>> For repeated merges, this meant, it tried to merge again the same = stuff starting at the branching point, which lead to conflicts with = later changes at the same places. >>> So you had to manually specify, what should be merged. >>=20 >> Newer subversions are only marginally worse than mercurial from what = I've done, but my recent experience has been much more slanted to = mercurial than subversion, so that impression suffers from a small = sample size. >=20 > Subversion is plain too slow. > The most extreme case, which I experienced, was git having finished a = moment after I hit enter, while svn took half an hour, because even = though the merge was simple, many files were involved and all the trips = over the internet took their toll (Also the bug above hit. This was the = point, where we switched from svn to git). > Also creating and checking out/switching branches is cumbersome. > It got better with the ^-notation for paths, but it still is not on = par with "git branch foo" and "git checkout foo". > The fact that creating a branch also creates a commit is cumbersome = and inspecting merged history is poor (compare with git log --graph = [optionally also add --oneline and --decorate] or hg log -G). > Interestingly, there is one thing, only git gets right: > git log (and many other commands) spawns a pager. > Plain hg/svn log is useless, because all the history scrolls by at = full speed. > You end up typing hg/svn log | less all the time. Yea, subversion is a big pain for anything but 'dolphin' branches. And = again, my complaints with what you say are 100% focused on = characterizing hg as reliable. Warner From owner-freebsd-arch@FreeBSD.ORG Sat Mar 2 01:18:39 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 ABD372BA for ; Sat, 2 Mar 2013 01:18:39 +0000 (UTC) (envelope-from jmg@h2.funkthat.com) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) by mx1.freebsd.org (Postfix) with ESMTP id 6FA24F7 for ; Sat, 2 Mar 2013 01:18:39 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id r221IXq7049309 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 1 Mar 2013 17:18:33 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id r221IX3X049308 for freebsd-arch@FreeBSD.org; Fri, 1 Mar 2013 17:18:33 -0800 (PST) (envelope-from jmg) Date: Fri, 1 Mar 2013 17:18:33 -0800 From: John-Mark Gurney To: freebsd-arch@FreeBSD.org Subject: return value from humanize_number Message-ID: <20130302011833.GM55866@funkthat.com> Mail-Followup-To: freebsd-arch@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Fri, 01 Mar 2013 17:18:33 -0800 (PST) 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, 02 Mar 2013 01:18:39 -0000 I picked up the work to fix up humanize_number, but now I have a problem.. Currently, if a number is too big to fit, we write what we can, and return the number of bytes we would of written if len allowed us.. The problem is that isn't what the man page says: The humanize_number() function returns the number of characters stored in buf (excluding the terminating NUL) upon success, or -1 upon failure. If HN_GETSCALE is specified, the prefix index number will be returned instead. It can return 21 even when len is 4, and we only store 3 characters in buf... So, the question is, do we fix the code to return an error if we attempt to write more than len - 1 characters, or do we change the man page to say that we return what we would like to have written, but only write out what we can (snprintf style, which is what we use)... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arch@FreeBSD.ORG Sat Mar 2 04:10:26 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 CB375F9F for ; Sat, 2 Mar 2013 04:10:26 +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 4612B859 for ; Sat, 2 Mar 2013 04:10:26 +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 r224AHuK040000 for ; Sat, 2 Mar 2013 06:10:17 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.0 kib.kiev.ua r224AHuK040000 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r224AHJE039998 for freebsd-arch@FreeBSD.org; Sat, 2 Mar 2013 06:10:17 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 2 Mar 2013 06:10:17 +0200 From: Konstantin Belousov To: freebsd-arch@FreeBSD.org Subject: Re: return value from humanize_number Message-ID: <20130302041017.GH2930@kib.kiev.ua> References: <20130302011833.GM55866@funkthat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NzX0AQGjRQPusK/O" Content-Disposition: inline In-Reply-To: <20130302011833.GM55866@funkthat.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 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, 02 Mar 2013 04:10:26 -0000 --NzX0AQGjRQPusK/O Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Mar 01, 2013 at 05:18:33PM -0800, John-Mark Gurney wrote: > I picked up the work to fix up humanize_number, but now I have a problem.. > Currently, if a number is too big to fit, we write what we can, and > return the number of bytes we would of written if len allowed us.. >=20 > The problem is that isn't what the man page says: > The humanize_number() function returns the number of characters stor= ed in > buf (excluding the terminating NUL) upon success, or -1 upon failure= =2E If > HN_GETSCALE is specified, the prefix index number will be returned > instead. >=20 > It can return 21 even when len is 4, and we only store 3 characters in > buf... >=20 > So, the question is, do we fix the code to return an error if we > attempt to write more than len - 1 characters, or do we change the > man page to say that we return what we would like to have written, but > only write out what we can (snprintf style, which is what we use)... I would say that the real solution is to finally make the libutil versioned and put the old version with old ABI under FBSD_1.2 version, making all the changes you consider worth it, for FBSD_1.3. --NzX0AQGjRQPusK/O Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRMXuoAAoJEJDCuSvBvK1Blp4P/3fJXsRSYgsQdGAgFJ47zctH hwYfjVkc3oGUxzVNXklzyF2CdzIDIWSyRJCgkzZV60eoOvs78cWI21zj7IPHyYU8 y10fWlSK3vcbB5phj5sNTd74RNPTmGOB8VUU3t0gNc9twIxSIfJzC1dWuz5Jdr0N x5PIOgAQ+xhmO4Hz65Bao2F0NhiZaMf1JBL+VssDT/Ih9xDm3OETtXsHbHx53JD9 T/PAWrqLUWo5ln7YqtTtx1UsedpiaubBb7K73Hp6Zf5XHoDz7GuFR/PpqEgLZBmT /2zW91z6342zeWNrdTRtM9nBQgqo2n03oQRofdKUkrF8ESyKUP+Zu7hzDw/unBH7 rKDqN8oee81acH3XH1bX9NWBv9As1t9grO+69sHsk5Y/AwfwRQd1h186ys1VZHoL q+mKTQkKkHs46Udk3nCZPjcsk8/q92n3/pYm/zh6qr0H7rAUUNj9LXg4+a/bhJpn xQF2m+peR8ikWARWPGam/TtzrMuq7su1tCTV+u4mgUOXg4zNR5qKqDqRp26vHyMa o2ubnW6XKLJzshPs5yhWZaRwTAIJIzGSWtdNiQZ9fYYeHN/R4HPm2crl1jaWpCz6 ig6DROcIjMxtEi/cxCRDFLldKOlm5Icz6zof+VtaNToIsDkw/8fmZWkY82aIv/ao 1AAP+10L58ng1qCt914c =m68S -----END PGP SIGNATURE----- --NzX0AQGjRQPusK/O-- From owner-freebsd-arch@FreeBSD.ORG Sat Mar 2 16:52:44 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 9839631D; Sat, 2 Mar 2013 16:52:44 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by mx1.freebsd.org (Postfix) with ESMTP id 16E4F790; Sat, 2 Mar 2013 16:52:43 +0000 (UTC) Received: by mail-wi0-f172.google.com with SMTP id ez12so553838wid.17 for ; Sat, 02 Mar 2013 08:52:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:date:from:to:subject:message-id:mime-version :content-type:content-disposition:user-agent; bh=MmoXJz7jLtSlaQ7zU8aE7ChTlXcjG2pAgDCExVhyUdo=; b=LZfJWHXQNpQp/ybD4ENkXGqywy3XkIfps9F+ISB95Nml05Ae67SVxCvuRw9GsPXH/5 WBJ8y3EIPubEYjA35BlOz6K3h8uvFy/7vy5bHbfTTbKO+h+LwkhUOfzpMMs/PCkO9h7w qcApKVSHIHQY6ETStezGCMijodM2kH/66LLzBPHYXMburlnQ4m8tQbrTvNiqL4A5ciD7 kFCkLk2PNdtZvqH9E5nEtH4582YR5bov8GXiRVLazMnf5QYt7KAaxS6tHQ9EXjni+7TL FxPtP22ARLxYpuHN3Llei0CrmWH14TRCYNgW+rxWqeAraAWUCYTR7pRyFuud9pSZkiiP KLmQ== X-Received: by 10.194.87.229 with SMTP id bb5mr23405414wjb.32.1362243162906; Sat, 02 Mar 2013 08:52:42 -0800 (PST) Received: from ithaqua.etoilebsd.net (ithaqua.etoilebsd.net. [37.59.37.188]) by mx.google.com with ESMTPS id fx5sm4567525wib.11.2013.03.02.08.52.41 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 02 Mar 2013 08:52:41 -0800 (PST) Sender: Baptiste Daroussin Date: Sat, 2 Mar 2013 17:52:39 +0100 From: Baptiste Daroussin To: arch@FreeBSD.org, current@FreeBSD.org Subject: Import libyaml into base Message-ID: <20130302165239.GB27078@ithaqua.etoilebsd.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jq0ap7NbKX2Kqbes" Content-Disposition: inline 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: Sat, 02 Mar 2013 16:52:44 -0000 --jq0ap7NbKX2Kqbes Content-Type: text/plain; charset=us-ascii Content-Disposition: inline hi, I want to import libyaml into base as libbsdyml so that no ports will use it like we do for expat. I need it for the pkg bootstrap, so it it can parse pkg.conf. I know that some of the bhyve people will also be glad to use it. libyaml is MIT licensed, it is stable: no abi/api revolution in it for a while. Does anyone have an objection? regards, Bapt --jq0ap7NbKX2Kqbes Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlEyLlcACgkQ8kTtMUmk6Ew8BwCfexYVs8FgtiANTz0IP7smTCA3 CvUAn2xgeyxOvvts+2qhLJPq5lGAOFfa =cTMW -----END PGP SIGNATURE----- --jq0ap7NbKX2Kqbes-- From owner-freebsd-arch@FreeBSD.ORG Sat Mar 2 18:08: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 9BC2532E for ; Sat, 2 Mar 2013 18:08:47 +0000 (UTC) (envelope-from mjacob@freebsd.org) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.freebsd.org (Postfix) with ESMTP id 6E4C4AB2 for ; Sat, 2 Mar 2013 18:08:47 +0000 (UTC) Received: from [192.168.135.7] (76-14-49-207.sf-cable.astound.net [76.14.49.207]) (authenticated bits=0) by ns1.feral.com (8.14.6/8.14.4) with ESMTP id r22I8eNU072658 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Sat, 2 Mar 2013 10:08:40 -0800 (PST) (envelope-from mjacob@freebsd.org) Message-ID: <51324024.2070800@freebsd.org> Date: Sat, 02 Mar 2013 10:08:36 -0800 From: Matthew Jacob Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: freebsd-arch@freebsd.org Subject: Re: Import libyaml into base References: <20130302165239.GB27078@ithaqua.etoilebsd.net> In-Reply-To: <20130302165239.GB27078@ithaqua.etoilebsd.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (ns1.feral.com [192.67.166.1]); Sat, 02 Mar 2013 10:08:41 -0800 (PST) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: mjacob@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2013 18:08:47 -0000 On 3/2/2013 8:52 AM, Baptiste Daroussin wrote: > hi, > > I want to import libyaml into base as libbsdyml so that no ports will use it > like we do for expat. > > I need it for the pkg bootstrap, so it it can parse pkg.conf. > I guess I don't see why it needs to be in the base system. Nothing specific to base needs it. From owner-freebsd-arch@FreeBSD.ORG Sat Mar 2 18:10:50 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 79861413; Sat, 2 Mar 2013 18:10:50 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) by mx1.freebsd.org (Postfix) with ESMTP id E9801AE6; Sat, 2 Mar 2013 18:10:49 +0000 (UTC) Received: by mail-wi0-f179.google.com with SMTP id ez12so612361wid.0 for ; Sat, 02 Mar 2013 10:10:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=YHwA6rSnK4eI6WaFhlRpp3XKgurvrlvYW08Ll/oWk2k=; b=Z+IcTckFu1hwG+P27JS2fQW73gS6nGyR+k7QQbD4LcA746jdEFXJo0k/4csIMwfjQZ CC96M7Olo/dR+9B5rn1YSIjAgCBKhUR2r9ltlLVN1lEOO9is8yQ4vP/dUv6k5wHUS8Ae runOIA0/mzvetwAS03eWxX1Hc7mO2X5+Dk3QV+FT/wQrnYXuchyQvyHQMD024+ZtJ3WZ c+qxtsnuo5OYtrSyIMDrNjzIW7Y0kpdmJc+crR6t9bjG1oD/7QpZ/vz5H5PQjaBTzLHw zICECpozmFscnErFpNPqKZqUdzTxnbz/fJjB9IAuIewIC95t4RgZSenyrtNDEjv6apKP EOLg== X-Received: by 10.194.133.98 with SMTP id pb2mr23762643wjb.20.1362247843206; Sat, 02 Mar 2013 10:10:43 -0800 (PST) Received: from ithaqua.etoilebsd.net (ithaqua.etoilebsd.net. [37.59.37.188]) by mx.google.com with ESMTPS id bs6sm5024250wib.4.2013.03.02.10.10.41 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 02 Mar 2013 10:10:42 -0800 (PST) Sender: Baptiste Daroussin Date: Sat, 2 Mar 2013 19:10:40 +0100 From: Baptiste Daroussin To: Matthew Jacob Subject: Re: Import libyaml into base Message-ID: <20130302181040.GB64570@ithaqua.etoilebsd.net> References: <20130302165239.GB27078@ithaqua.etoilebsd.net> <51324024.2070800@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="R3G7APHDIzY6R/pk" Content-Disposition: inline In-Reply-To: <51324024.2070800@freebsd.org> 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: Sat, 02 Mar 2013 18:10:50 -0000 --R3G7APHDIzY6R/pk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Mar 02, 2013 at 10:08:36AM -0800, Matthew Jacob wrote: > On 3/2/2013 8:52 AM, Baptiste Daroussin wrote: > > hi, > > > > I want to import libyaml into base as libbsdyml so that no ports will u= se it > > like we do for expat. > > > > I need it for the pkg bootstrap, so it it can parse pkg.conf. > > > I guess I don't see why it needs to be in the base system. Nothing=20 > specific to base needs it. >=20 pkg bootstrap is in the base system. see usr.sbin/pkg The regular pkgng already uses it regards, Bapt --R3G7APHDIzY6R/pk Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlEyQKAACgkQ8kTtMUmk6Exr5wCgl0dHs3le4qFEQJT6SI18Skjm 7g0AoMAMRxBD4klob61xb0vhTTvFzY60 =+RwY -----END PGP SIGNATURE----- --R3G7APHDIzY6R/pk-- From owner-freebsd-arch@FreeBSD.ORG Sat Mar 2 18:12: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 B081C4FD; Sat, 2 Mar 2013 18:12:36 +0000 (UTC) (envelope-from grehan@freebsd.org) Received: from alto.onthenet.com.au (alto.OntheNet.com.au [203.13.68.12]) by mx1.freebsd.org (Postfix) with ESMTP id 54469AF7; Sat, 2 Mar 2013 18:12:36 +0000 (UTC) Received: from dommail.onthenet.com.au (dommail.OntheNet.com.au [203.13.70.57]) by alto.onthenet.com.au (Postfix) with ESMTPS id 60C1F11E1D; Sun, 3 Mar 2013 04:12:21 +1000 (EST) Received: from Peter-Grehans-MacBook-Pro.local (c-67-190-11-104.hsd1.co.comcast.net [67.190.11.104]) by dommail.onthenet.com.au (MOS 4.2.4-GA) with ESMTP id BKI05120 (AUTH peterg@ptree32.com.au); Sun, 3 Mar 2013 04:12:20 +1000 Message-ID: <51324101.8070408@freebsd.org> Date: Sat, 02 Mar 2013 11:12:17 -0700 From: Peter Grehan User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.28) Gecko/20120306 Thunderbird/3.1.20 MIME-Version: 1.0 To: mjacob@freebsd.org Subject: Re: Import libyaml into base References: <20130302165239.GB27078@ithaqua.etoilebsd.net> <51324024.2070800@freebsd.org> In-Reply-To: <51324024.2070800@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Sat, 02 Mar 2013 18:12:36 -0000 Hi Matt, > I guess I don't see why it needs to be in the base system. Nothing > specific to base needs it. bhyve would like to use it for a config file. At some point in the near future I would have sent the same email that Baptiste just did :) later, Peter. From owner-freebsd-arch@FreeBSD.ORG Sat Mar 2 18:26:53 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 4405A977; Sat, 2 Mar 2013 18:26:53 +0000 (UTC) (envelope-from mjacob@freebsd.org) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.freebsd.org (Postfix) with ESMTP id 6AF45B8B; Sat, 2 Mar 2013 18:26:51 +0000 (UTC) Received: from [192.168.135.7] (76-14-49-207.sf-cable.astound.net [76.14.49.207]) (authenticated bits=0) by ns1.feral.com (8.14.6/8.14.4) with ESMTP id r22IQlcd072766 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sat, 2 Mar 2013 10:26:51 -0800 (PST) (envelope-from mjacob@freebsd.org) Message-ID: <51324463.6040407@freebsd.org> Date: Sat, 02 Mar 2013 10:26:43 -0800 From: Matthew Jacob Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Baptiste Daroussin Subject: Re: Import libyaml into base References: <20130302165239.GB27078@ithaqua.etoilebsd.net> <51324024.2070800@freebsd.org> <20130302181040.GB64570@ithaqua.etoilebsd.net> In-Reply-To: <20130302181040.GB64570@ithaqua.etoilebsd.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (ns1.feral.com [192.67.166.1]); Sat, 02 Mar 2013 10:26:51 -0800 (PST) Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: mjacob@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2013 18:26:53 -0000 On 3/2/2013 10:10 AM, Baptiste Daroussin wrote: > > pkg bootstrap is in the base system. see usr.sbin/pkg > > The regular pkgng already uses it > > regards, > Bapt Oh, ok. I guess I missed that. Thanks. N'mind. From owner-freebsd-arch@FreeBSD.ORG Sat Mar 2 23:10:40 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 AA6D18CE; Sat, 2 Mar 2013 23:10:40 +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 70FF3868; Sat, 2 Mar 2013 23:10:40 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 847E5358C5A; Sun, 3 Mar 2013 00:10:38 +0100 (CET) Received: by snail.stack.nl (Postfix, from userid 1677) id 639312848C; Sun, 3 Mar 2013 00:10:38 +0100 (CET) Date: Sun, 3 Mar 2013 00:10:38 +0100 From: Jilles Tjoelker To: Pawel Jakub Dawidek Subject: Re: bindat(2) and connectat(2) syscalls for review. Message-ID: <20130302231038.GA70271@stack.nl> References: <20130213230354.GC1375@garage.freebsd.pl> <20130213232004.GA2522@kib.kiev.ua> <20130213234030.GD1375@garage.freebsd.pl> <20130214185549.GA36288@stack.nl> <86ip5saqiu.fsf@ds4.des.no> <20130216232039.GD2023@garage.freebsd.pl> <86y5enaan7.fsf@ds4.des.no> <20130217142038.GA55034@stack.nl> <20130217144321.GJ2023@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130217144321.GJ2023@garage.freebsd.pl> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Konstantin Belousov , Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= , 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: Sat, 02 Mar 2013 23:10:40 -0000 On Sun, Feb 17, 2013 at 03:43:22PM +0100, Pawel Jakub Dawidek wrote: > But if we are going to do that, it would be nice to have at least one > useful flag to use in there:) I have just found a candidate. In a kdump of tmux, there is a umask/bind/umask sequence. This is because unlike other calls that create files such as open(), mkdir(), mkfifo() and mknod(), the bind() function does not have a permissions argument. (symlink() has no permissions argument but that's because permissions do not matter for symlinks.) The umask/bind/umask sequence is not thread-safe. If the socket is to be accessible for the current user only, a good workaround is to create the socket in a mode 700 directory and not care about the permissions of the socket itself. If the socket is to be accessible for all users, some other filename can be bound, permissions corrected and then renamed to the expected name. In some cases, these workarounds may have to be combined. If we want a cleaner fix for this, it can be done with an extra bindat() argument, a setsockopt() or wider-ranging changes like a per-thread umask. Then again, it is apparently OK that not all filenames are accessible for binding and connecting sockets, so perhaps this is also OK. Some of these umask problems are shared with all other calls that create files. -- Jilles Tjoelker