From owner-freebsd-arch@FreeBSD.ORG Sun Aug 3 00:48:32 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B43182E8; Sun, 3 Aug 2014 00:48:32 +0000 (UTC) Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 68E5C23F3; Sun, 3 Aug 2014 00:48:32 +0000 (UTC) Received: by mail-qg0-f44.google.com with SMTP id e89so7471620qgf.17 for ; Sat, 02 Aug 2014 17:48:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=GJZ26BbHCzuoGVWetmXAulBlrlqHDfHes/J0/AjEyVc=; b=laDlfLhEBNyPaaJb6mGB9cqShJFWehFx1kJ2k/Y4bMQ6B49xkQ4+/hIYyBqnykD2DA Lv1li6tUb5aJM4+yGiMEV+sEfq7YoU4aqPlWVrWNc2hZchWCTAjxF3HYYARGk44R9znB Wf6w3MniqOSUq7jst2bXIRdQztSyrLTdHVxhYGq89kv/ks3Ty1ACF6ih0BB4I5nFDmdk bmnpgXlNcr0P4DJJj8ERyNnVtBjpCHnV7zcKx1q362kLsHpTieMbLiOydF+dT0VA9wWf m/bdUe/re7/+o+lrCOTIXTYE51bRhAmM70497QinB4YUlYRQCkzD98LAR8WKFEpPw99W uQ8Q== MIME-Version: 1.0 X-Received: by 10.224.55.131 with SMTP id u3mr23103065qag.98.1407026911560; Sat, 02 Aug 2014 17:48:31 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.1.6 with HTTP; Sat, 2 Aug 2014 17:48:31 -0700 (PDT) Date: Sat, 2 Aug 2014 17:48:31 -0700 X-Google-Sender-Auth: O0AGsM1IjsDd0SXMzZ_GMC0nz8E Message-ID: Subject: [rfc] UDP RSS awareness; handling IPv4 fragments From: Adrian Chadd To: FreeBSD Net , "freebsd-arch@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Aug 2014 00:48:32 -0000 Hi! http://people.freebsd.org/~adrian/rss/20140802-rss-udp-ip-fragments-1.diff This implements the RSS awareness bits for UDPv4, UDPv6 and IP fragment handling. It should work for UDP transmit and receive. There's a phabricator review: https://phabric.freebsd.org/D527 I'll finish off IPv6 RSS after this and then look at the various ways that packets make their way in and out of the stack. There's a whole lot of silliness with multicast and IP tunneling / IPSEC decapsulation that requires a recompute of the hash. I appreciate any/all feedback and testing! Especially testing! Thanks! -a From owner-freebsd-arch@FreeBSD.ORG Mon Aug 4 12:52:49 2014 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AFF126D7; Mon, 4 Aug 2014 12:52:49 +0000 (UTC) Received: from mx1.sbone.de (bird.sbone.de [46.4.1.90]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 655722836; Mon, 4 Aug 2014 12:52:48 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 5C2A525D3A8F; Mon, 4 Aug 2014 12:52:40 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 898C3C25F5C; Mon, 4 Aug 2014 12:52:39 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id E3RNOI9ffDiH; Mon, 4 Aug 2014 12:52:38 +0000 (UTC) Received: from [IPv6:fde9:577b:c1a9:4420:cabc:c8ff:fe8b:4fe6] (unknown [IPv6:fde9:577b:c1a9:4420:cabc:c8ff:fe8b:4fe6]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 08F5CC25F5A; Mon, 4 Aug 2014 12:52:36 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: [CFT] Autofs. From: "Bjoern A. Zeeb" In-Reply-To: <20140730071933.GA20122@pc5.home> Date: Mon, 4 Aug 2014 12:52:32 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <3DA39B51-4CE5-437B-9B03-7E34CC954A7E@lists.zabbadoz.net> References: <20140730071933.GA20122@pc5.home> To: =?utf-8?Q?Edward_Tomasz_Napiera=C5=82a?= X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-current@FreeBSD.org, freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 12:52:49 -0000 On 30 Jul 2014, at 07:19 , Edward Tomasz Napiera=C5=82a = wrote: > At the link below you will find a patch that adds the new automounter. > The patch is against yesterdays 11.0-CURRENT. >=20 > http://people.freebsd.org/~trasz/autofs-head-20140729.diff I also just submitted = https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D192379 to allow -o = vers=3D mount_nfs compatibility, which makes it easier to integrate with = Linux/OSX/Solaris LDAP setups and mount options from LDAP. > Testing is welcome. Please start with manual pages, eg. automount(8). I found one case now doing the aforementioned where when the initial = mount_nfs fails (e.g., for invalid options), then a later mount did not = succeed either, with the correct mount options; I did try to run = automount -u in between tries, as well as service automountd restart, = but that did not make a change; given I was short on time, a reboot of = my desktop made this go away. Is there some =E2=80=9Cnegative = caching=E2=80=9D in the kernel module possibly that will not retry the = mount for another time or something=E2=80=94as in if I were more patient = and waited 5 minutes, would it maybe just have worked again? Bjoern =E2=80=94=20 Bjoern A. Zeeb "Come on. Learn, goddamn it.", WarGames, 1983 From owner-freebsd-arch@FreeBSD.ORG Mon Aug 4 14:50:00 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EC83DFEF; Mon, 4 Aug 2014 14:49:59 +0000 (UTC) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0188.outbound.protection.outlook.com [207.46.163.188]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7C2B128B8; Mon, 4 Aug 2014 14:49:58 +0000 (UTC) Received: from BY2PR05CA010.namprd05.prod.outlook.com (10.242.32.40) by BLUPR05MB722.namprd05.prod.outlook.com (10.141.207.150) with Microsoft SMTP Server (TLS) id 15.0.995.14; Mon, 4 Aug 2014 14:49:42 +0000 Received: from BN1BFFO11FD026.protection.gbl (2a01:111:f400:7c10::1:197) by BY2PR05CA010.outlook.office365.com (2a01:111:e400:2c2a::40) with Microsoft SMTP Server (TLS) id 15.0.995.14 via Frontend Transport; Mon, 4 Aug 2014 14:49:41 +0000 Received: from P-EMF02-SAC.jnpr.net (66.129.239.16) by BN1BFFO11FD026.mail.protection.outlook.com (10.58.144.89) with Microsoft SMTP Server (TLS) id 15.0.990.10 via Frontend Transport; Mon, 4 Aug 2014 14:49:40 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF02-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 4 Aug 2014 07:49:39 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id s74EnSn38603; Mon, 4 Aug 2014 07:49:28 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id s74Emwk0019816; Mon, 4 Aug 2014 10:49:08 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-ID: <201408041449.s74Emwk0019816@idle.juniper.net> To: Poul-Henning Kamp Subject: Re: XML Output: libxo - provide single API to output TXT, XML, JSON and HTML In-Reply-To: <63132.1406924887@critter.freebsd.dk> Date: Mon, 4 Aug 2014 10:48:58 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:66.129.239.16; CTRY:US; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(6009001)(199002)(189002)(164054003)(92566001)(83072002)(48376002)(92726001)(85852003)(46102001)(50986999)(77982001)(107046002)(110136001)(50466002)(53416004)(54356999)(44976005)(76482001)(102836001)(83322001)(86362001)(84676001)(6806004)(97736001)(99396002)(87936001)(103666002)(4396001)(68736004)(69596002)(31966008)(74502001)(74662001)(76506005)(81156004)(106466001)(64706001)(47776003)(21056001)(20776003)(80022001)(79102001)(105596002)(81342001)(81542001)(85306004)(95666004); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB722; H:P-EMF02-SAC.jnpr.net; FPR:; MLV:sfv; PTR:ErrorRetry; A:1; MX:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-Forefront-PRVS: 0293D40691 Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.16 as permitted sender) Authentication-Results: spf=softfail (sender IP is 66.129.239.16) smtp.mailfrom=phil@juniper.net; X-OriginatorOrg: juniper.net Cc: arch@freebsd.org, John-Mark Gurney , marcel@freebsd.org, "Simon J. Gerraty" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 14:50:00 -0000 Poul-Henning Kamp writes: >First of, this is not just ENOMEM, this is also invalid UTF-8 strings, >NULL pointers and much more bogosity. Yup, there are 26 failure cases at present, ranging from missing close braces in format strings to unbalanced open/close calls. >>Seeing broken output is better than limping >>along with output that looks right but isn't. >The output should preferably be explicitly broken, so that nobody >downstream mistakenly takes it and runs with it. I think we're in agreement, but there is the question of what constitutes sufficient problems to trigger abort. I'm coding the UTF-8 support now and that's a perfect example. If the output character set (the user's LANG setting) doesn't support a character of output (u+10d6), does that constitute a complete failure? I'll assumably give flags to tailor the behavior, but by default, I'd be upset if character conversion issues like this turned into complete failure. But a format string with an invalid UTF-8 sequence would be more severe. FWIW, the UTF-8 strategy for libox is this: - all format strings are UTF-8 - argument strings (%s) are UTF-8 - "%ls" handles wide characters - "%hs" will handle locale-based strings - XML, JSON, and HTML will be UTF-8 output - text will be locale-based The painful part is that I've been using vsnprintf as the plumbing for formatting strings, but it doesn't handle field widths for UTF-8 data correctly, so I'll need to start doing that by handle myself. Thanks, Phil From owner-freebsd-arch@FreeBSD.ORG Mon Aug 4 14:58:33 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 34BD1389; Mon, 4 Aug 2014 14:58:33 +0000 (UTC) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0206.outbound.protection.outlook.com [207.46.163.206]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 629D029FF; Mon, 4 Aug 2014 14:58:32 +0000 (UTC) Received: from BL2PR05CA0045.namprd05.prod.outlook.com (10.255.226.45) by BY2PR05MB726.namprd05.prod.outlook.com (10.141.223.19) with Microsoft SMTP Server (TLS) id 15.0.995.14; Mon, 4 Aug 2014 14:58:22 +0000 Received: from BL2FFO11FD045.protection.gbl (2a01:111:f400:7c09::142) by BL2PR05CA0045.outlook.office365.com (2a01:111:e400:c04::45) with Microsoft SMTP Server (TLS) id 15.0.995.14 via Frontend Transport; Mon, 4 Aug 2014 14:58:21 +0000 Received: from P-EMF02-SAC.jnpr.net (66.129.239.16) by BL2FFO11FD045.mail.protection.outlook.com (10.173.161.207) with Microsoft SMTP Server (TLS) id 15.0.990.10 via Frontend Transport; Mon, 4 Aug 2014 14:58:21 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF02-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 4 Aug 2014 07:58:20 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id s74Ew5n43616; Mon, 4 Aug 2014 07:58:06 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id s74EvXKg019899; Mon, 4 Aug 2014 10:57:39 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-ID: <201408041457.s74EvXKg019899@idle.juniper.net> To: John-Mark Gurney Subject: Re: XML Output: libxo - provide single API to output TXT, XML, JSON and HTML In-Reply-To: <20140801175906.GA50495@funkthat.com> Date: Mon, 4 Aug 2014 10:57:33 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:66.129.239.16; CTRY:US; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(6009001)(164054003)(199002)(189002)(110136001)(69596002)(50466002)(53416004)(68736004)(87936001)(4396001)(97736001)(92566001)(80022001)(92726001)(86362001)(74502001)(74662001)(85306004)(102836001)(54356999)(85852003)(103666002)(50986999)(83072002)(107046002)(84676001)(48376002)(47776003)(95666004)(76506005)(6806004)(105596002)(81542001)(81342001)(99396002)(31966008)(64706001)(20776003)(77982001)(46102001)(79102001)(106466001)(76482001)(83322001)(44976005)(81156004)(21056001); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB726; H:P-EMF02-SAC.jnpr.net; FPR:; MLV:sfv; PTR:InfoDomainNonexistent; MX:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-Forefront-PRVS: 0293D40691 Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.16 as permitted sender) Authentication-Results: spf=softfail (sender IP is 66.129.239.16) smtp.mailfrom=phil@juniper.net; X-OriginatorOrg: juniper.net Cc: arch@freebsd.org, Poul-Henning Kamp , "Simon J. Gerraty" , Marcel Moolenaar , Marcel Moolenaar X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 14:58:33 -0000 John-Mark Gurney writes: >The just pushed the error handling further down stream... I'd trust >a parse error more than someone handling all the odd edge cases of >missing tags, or even failure to parse the error tag... Yes, I'd rather see output that is obviously broken and prevents a parser (JSON or XML) from returning success than parsable output with a message that we're depending on the client to parse and case about. From phk's example, how many will write: grep --xpath some/tag/i/care/about `du --xml` and not even notice the error tag, which would require something like: grep --xpath 'some[not(//error)]/tag/i/care/about' `du --xml` where the cost of "//error" (searching the entire output tree for an error tag) might be huge. And doing this in JSON would be worse, since there's no XPath for JSON (yet). >Either choice we make pushes the error handling down stream... One case, >it's the parser, the other case it's the consumer of the parser, but in >both cases the downstream HAS to properly handle the error however it >is signaled... Sure, but I'd rather trust the parser library to say "this is junk" than do trust the client app to handle exception information in the output data. Thanks, Phil From owner-freebsd-arch@FreeBSD.ORG Mon Aug 4 16:17:11 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3A5C2B21; Mon, 4 Aug 2014 16:17:11 +0000 (UTC) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9E0592566; Mon, 4 Aug 2014 16:17:10 +0000 (UTC) Received: by mail-we0-f180.google.com with SMTP id w61so7885752wes.25 for ; Mon, 04 Aug 2014 09:17:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-type:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=BssA/C/kbOXvuXH2a0TGeeDDA+1jqGQdZ4/oi0mHk+k=; b=GdDq0AWR9Bb0GWkik2Gtep7KUFCW62cjmPyjdCWaz4jyQEPemzaY96Ex9cKtSh0QcS IrrIrFeROI6FFcPrXoEZ0lqpC9cID+w7DvkjhhCA6jXjS0zEUazahwtqftT3V5i5pKmn Ohxv6hJ7yRAx7wPAi88EgqpaVQoE8AKDgwx/qyq586Ghi6VIgKoSu+/370dmr4cWthwJ c2KqOs6fU/3VyJqwink2rSkO5cKXibYvPFYjf5ecQesBbMRzlpCfN4+FI6fvrTAyYBRJ Am5oW5o9yirTT+xct433FPBdcLLX3EX+T93lU7+ia91R7iKkXwUqT4rPaoyXXDxMhr8j 5O6w== X-Received: by 10.194.6.101 with SMTP id z5mr33836739wjz.79.1407169025676; Mon, 04 Aug 2014 09:17:05 -0700 (PDT) Received: from pc5.home (adhg143.neoplus.adsl.tpnet.pl. [79.184.162.143]) by mx.google.com with ESMTPSA id m1sm37783346wiy.7.2014.08.04.09.17.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 Aug 2014 09:17:05 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Mon, 4 Aug 2014 18:17:10 +0200 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= To: "Bjoern A. Zeeb" Subject: Re: [CFT] Autofs. Message-ID: <20140804161710.GA32801@pc5.home> Mail-Followup-To: "Bjoern A. Zeeb" , freebsd-current@FreeBSD.org, freebsd-arch@FreeBSD.org References: <20140730071933.GA20122@pc5.home> <3DA39B51-4CE5-437B-9B03-7E34CC954A7E@lists.zabbadoz.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3DA39B51-4CE5-437B-9B03-7E34CC954A7E@lists.zabbadoz.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@FreeBSD.org, freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 16:17:11 -0000 On 0804T1252, Bjoern A. Zeeb wrote: > On 30 Jul 2014, at 07:19 , Edward Tomasz Napierała wrote: > > > At the link below you will find a patch that adds the new automounter. > > The patch is against yesterdays 11.0-CURRENT. > > > > http://people.freebsd.org/~trasz/autofs-head-20140729.diff > > I also just submitted https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192379 to allow -o vers= mount_nfs compatibility, which makes it easier to integrate with Linux/OSX/Solaris LDAP setups and mount options from LDAP. Nice! Will you commit it? > > Testing is welcome. Please start with manual pages, eg. automount(8). > > > I found one case now doing the aforementioned where when the initial mount_nfs fails (e.g., for invalid options), then a later mount did not succeed either, with the correct mount options; I did try to run automount -u in between tries, as well as service automountd restart, but that did not make a change; given I was short on time, a reboot of my desktop made this go away. Is there some “negative caching” in the kernel module possibly that will not retry the mount for another time or something—as in if I were more patient and waited 5 minutes, would it maybe just have worked again? There is no negative caching. I'll see if I can figure out the cause for this. From owner-freebsd-arch@FreeBSD.ORG Mon Aug 4 16:35:25 2014 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3B7F54D6; Mon, 4 Aug 2014 16:35:25 +0000 (UTC) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E5203278C; Mon, 4 Aug 2014 16:35:24 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 827DA25D3810; Mon, 4 Aug 2014 16:35:22 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id A12F7C26033; Mon, 4 Aug 2014 16:35:21 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id XEZJxJIN6D5n; Mon, 4 Aug 2014 16:35:20 +0000 (UTC) Received: from [IPv6:fde9:577b:c1a9:4420:cabc:c8ff:fe8b:4fe6] (unknown [IPv6:fde9:577b:c1a9:4420:cabc:c8ff:fe8b:4fe6]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 45C0CC26030; Mon, 4 Aug 2014 16:35:17 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: [CFT] Autofs. From: "Bjoern A. Zeeb" In-Reply-To: <20140804161710.GA32801@pc5.home> Date: Mon, 4 Aug 2014 16:35:15 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <5C88BFBD-798C-4F99-92E2-5F75FE622613@lists.zabbadoz.net> References: <20140730071933.GA20122@pc5.home> <3DA39B51-4CE5-437B-9B03-7E34CC954A7E@lists.zabbadoz.net> <20140804161710.GA32801@pc5.home> To: =?utf-8?Q?Edward_Tomasz_Napiera=C5=82a?= X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-current@FreeBSD.org, freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 16:35:25 -0000 On 04 Aug 2014, at 16:17 , Edward Tomasz Napiera=C5=82a = wrote: > On 0804T1252, Bjoern A. Zeeb wrote: >> On 30 Jul 2014, at 07:19 , Edward Tomasz Napiera=C5=82a = wrote: >>=20 >>> At the link below you will find a patch that adds the new = automounter. >>> The patch is against yesterdays 11.0-CURRENT. >>>=20 >>> http://people.freebsd.org/~trasz/autofs-head-20140729.diff >>=20 >> I also just submitted = https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D192379 to allow -o = vers=3D mount_nfs compatibility, which makes it easier to integrate with = Linux/OSX/Solaris LDAP setups and mount options from LDAP. >=20 > Nice! Will you commit it? Yeah and MFC for 10.1 unless someone speaks up the next day or two. I = have updated the man page locally and I emailed Rick Macklem; will see = if he=E2=80=99s around. >>> Testing is welcome. Please start with manual pages, eg. = automount(8). >>=20 >>=20 >> I found one case now doing the aforementioned where when the initial = mount_nfs fails (e.g., for invalid options), then a later mount did not = succeed either, with the correct mount options; I did try to run = automount -u in between tries, as well as service automountd restart, = but that did not make a change; given I was short on time, a reboot of = my desktop made this go away. Is there some =E2=80=9Cnegative = caching=E2=80=9D in the kernel module possibly that will not retry the = mount for another time or something=E2=80=94as in if I were more patient = and waited 5 minutes, would it maybe just have worked again? >=20 > There is no negative caching. I'll see if I can figure out the cause > for this. Thanks. I can possibly try to do some more tracing and debugging later = in the week if needed. =E2=80=94=20 Bjoern A. Zeeb "Come on. Learn, goddamn it.", WarGames, 1983 From owner-freebsd-arch@FreeBSD.ORG Mon Aug 4 17:41:52 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 92511FA9; Mon, 4 Aug 2014 17:41:52 +0000 (UTC) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F3FED21D8; Mon, 4 Aug 2014 17:41:51 +0000 (UTC) Received: by mail-we0-f180.google.com with SMTP id w61so8131272wes.39 for ; Mon, 04 Aug 2014 10:41:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-type:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=pg1Olvv6j8jiXU1Q8+gDz7CFz6pdXrEZ1KXGPJFM8Eo=; b=GGoG3xdXleAFhznhMPYSNHWQKv6w3FLDwfa5Nwl4ViaF47xAHJbg/EZ0sgbxjC5osg uJq0HDmwL9oXSX44WzsbsSZ3Ui9KVF7JgF2uNKR4WhrG+4N+sSRuQPEL+dKbp2egE+Uy zhD44WsmEwYvdK6SaH/0t+HiHbl1SJ7hsKmigUiYflwLAweTiWoTRqc1Xj6hEFqXFP2G svSIUD0XGmjoiVzhcVQTBOzts/JOsra7hWt45aedl1zcDvTJ49rm3zBwrDzFdBpxNbFU 6KN+011ax51shlJc9xCvXB1HwdcEKr01W+wdnM0p/RgMqbtxBkdGMYcwAhgCtyqDw5vJ 0E2A== X-Received: by 10.180.39.172 with SMTP id q12mr31003625wik.55.1407174109991; Mon, 04 Aug 2014 10:41:49 -0700 (PDT) Received: from pc5.home (adhg143.neoplus.adsl.tpnet.pl. [79.184.162.143]) by mx.google.com with ESMTPSA id 10sm45007077wjx.26.2014.08.04.10.41.48 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 Aug 2014 10:41:49 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Mon, 4 Aug 2014 19:41:53 +0200 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= To: "Bjoern A. Zeeb" Subject: Re: [CFT] Autofs. Message-ID: <20140804174153.GA33041@pc5.home> Mail-Followup-To: "Bjoern A. Zeeb" , freebsd-current@FreeBSD.org, freebsd-arch@FreeBSD.org References: <20140730071933.GA20122@pc5.home> <3DA39B51-4CE5-437B-9B03-7E34CC954A7E@lists.zabbadoz.net> <20140804161710.GA32801@pc5.home> <5C88BFBD-798C-4F99-92E2-5F75FE622613@lists.zabbadoz.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5C88BFBD-798C-4F99-92E2-5F75FE622613@lists.zabbadoz.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@FreeBSD.org, freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 17:41:52 -0000 On 0804T1635, Bjoern A. Zeeb wrote: > > On 04 Aug 2014, at 16:17 , Edward Tomasz Napierała wrote: > > > On 0804T1252, Bjoern A. Zeeb wrote: > >> On 30 Jul 2014, at 07:19 , Edward Tomasz Napierała wrote: > >> > >>> At the link below you will find a patch that adds the new automounter. > >>> The patch is against yesterdays 11.0-CURRENT. > >>> > >>> http://people.freebsd.org/~trasz/autofs-head-20140729.diff > >> > >> I also just submitted https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192379 to allow -o vers= mount_nfs compatibility, which makes it easier to integrate with Linux/OSX/Solaris LDAP setups and mount options from LDAP. > > > > Nice! Will you commit it? > > Yeah and MFC for 10.1 unless someone speaks up the next day or two. I have updated the man page locally and I emailed Rick Macklem; will see if he’s around. Thanks! > >>> Testing is welcome. Please start with manual pages, eg. automount(8). > >> > >> > >> I found one case now doing the aforementioned where when the initial mount_nfs fails (e.g., for invalid options), then a later mount did not succeed either, with the correct mount options; I did try to run automount -u in between tries, as well as service automountd restart, but that did not make a change; given I was short on time, a reboot of my desktop made this go away. Is there some “negative caching” in the kernel module possibly that will not retry the mount for another time or something—as in if I were more patient and waited 5 minutes, would it maybe just have worked again? > > > > There is no negative caching. I'll see if I can figure out the cause > > for this. > > Thanks. I can possibly try to do some more tracing and debugging later in the week if needed. Ok. Now, to make sure I get it right: at first, the trigger failed, because of invalid mount options in map. The filesystem didn't get mounted, and the command that triggered the mount returned some kind of Input/Output Error. After fixing the map and trying to access the same directory again... what exactly happened at this point? In what way exactly did the second mount fail? From owner-freebsd-arch@FreeBSD.ORG Mon Aug 4 18:51:13 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 17128F4D; Mon, 4 Aug 2014 18:51:13 +0000 (UTC) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id AF35A2905; Mon, 4 Aug 2014 18:51:12 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AssEAG3V31ODaFve/2dsb2JhbABbFoNJVwSCdMk8CoZ3UwGBJ3eEAwEBAQMBAQEBICsgCwUWGAICDRkCKQEJJgYIBwQBHASIGQgNrWiXDBeBLI1PAQEbATMHgnmBUgWOWIo6hEiTC4NpIS8BBoEGOQ X-IronPort-AV: E=Sophos;i="5.01,799,1400040000"; d="scan'208";a="146251524" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-annu.net.uoguelph.ca with ESMTP; 04 Aug 2014 14:51:11 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 5B70083DA2; Mon, 4 Aug 2014 14:51:11 -0400 (EDT) Date: Mon, 4 Aug 2014 14:51:11 -0400 (EDT) From: Rick Macklem To: "Bjoern A. Zeeb" Message-ID: <1593472917.6916985.1407178271363.JavaMail.root@uoguelph.ca> In-Reply-To: <3DA39B51-4CE5-437B-9B03-7E34CC954A7E@lists.zabbadoz.net> Subject: Re: [CFT] Autofs. MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 7.2.6_GA_2926 (ZimbraWebClient - FF3.0 (Win)/7.2.6_GA_2926) Cc: freebsd-current@FreeBSD.org, Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= , freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 18:51:13 -0000 Bjoern A. Zeeb wrote: > On 30 Jul 2014, at 07:19 , Edward Tomasz Napiera=C5=82a > wrote: >=20 > > At the link below you will find a patch that adds the new > > automounter. > > The patch is against yesterdays 11.0-CURRENT. > >=20 > > http://people.freebsd.org/~trasz/autofs-head-20140729.diff >=20 > I also just submitted > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D192379 to allow -o > vers=3D mount_nfs compatibility, which makes it easier to integrate > with Linux/OSX/Solaris LDAP setups and mount options from LDAP. >=20 >=20 > > Testing is welcome. Please start with manual pages, eg. > > automount(8). >=20 >=20 > I found one case now doing the aforementioned where when the initial > mount_nfs fails (e.g., for invalid options), then a later mount did > not succeed either, with the correct mount options; I did try to > run automount -u in between tries, as well as service automountd > restart, but that did not make a change; given I was short on time, > a reboot of my desktop made this go away. Is there some =E2=80=9Cnegati= ve > caching=E2=80=9D in the kernel module possibly that will not retry the mo= unt > for another time or something=E2=80=94as in if I were more patient and > waited 5 minutes, would it maybe just have worked again? >=20 If I recall it correctly, it retries a mount attempt that fails after something like 1min (which seems like a long time when you are waiting for it;-). I think that was done so that clients don't flood a rebooting server with mount attempts, but that code was written long, long ago. rick ps: I just reviewed and thanked Bjoern for the -vers=3D patch. > Bjoern >=20 > =E2=80=94 > Bjoern A. Zeeb "Come on. Learn, goddamn it.", WarGames, > 1983 >=20 > _______________________________________________ > 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" From owner-freebsd-arch@FreeBSD.ORG Mon Aug 4 20:36:54 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 526DAB1A for ; Mon, 4 Aug 2014 20:36:54 +0000 (UTC) Received: from mail-oi0-f44.google.com (mail-oi0-f44.google.com [209.85.218.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 194A326AF for ; Mon, 4 Aug 2014 20:36:53 +0000 (UTC) Received: by mail-oi0-f44.google.com with SMTP id x69so4889724oia.17 for ; Mon, 04 Aug 2014 13:36:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:date:message-id:subject:from :to:content-type; bh=FJhRQR8DEiRNITie+QAINyjiRfo8UtP/p3/CGCPsapU=; b=iYf+wFgGlWyagtR8dlsJEUG3IynpPJKyj5NexBuopTiLbB3jUJuD012CpXrcqnGv10 +BFDM5MvFdKqIkJn9G6fDk9M09m7lKMXp4a6z4J4LdSWR3faVhc3817OtlaJ8Nj8o1hI qskjpuwPIsqsTPllUVu68um484TtqFVZx+vWW5TqiqppN7yqoFuh1mB8sj+JtwbX92WA qQEyItIgGJFxwm5NAtzI5N3qKc3VI/ELq7cCjLTzP26P1TwY0FUwaIM4wz7t6V6RCNzK BJIGEhGyYL+Bd86UHpMFgXp5XnClfbk17zW/4VHYBz70LBUavR3lPPhENMu5f42+C/Ja R4fw== X-Gm-Message-State: ALoCoQmSf58w+tE4gTVQSDd4vIeDL1Fb1YFaRQEleGHEfBYR+cLA1E4LCOh4kyxj3u7a6v27jvJ6 MIME-Version: 1.0 X-Received: by 10.60.52.5 with SMTP id p5mr35733766oeo.55.1407184607397; Mon, 04 Aug 2014 13:36:47 -0700 (PDT) Sender: scott@thinkmoore.net Received: by 10.60.35.71 with HTTP; Mon, 4 Aug 2014 13:36:47 -0700 (PDT) Date: Mon, 4 Aug 2014 16:36:47 -0400 X-Google-Sender-Auth: cHt5HEscsmvrDmCMophIaa6Qmy8 Message-ID: Subject: New hooks for MAC framework? From: Scott Moore To: freebsd-arch@freebsd.org Content-Type: multipart/mixed; boundary=001a11332c8ea872e904ffd3b22b X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 20:36:54 -0000 --001a11332c8ea872e904ffd3b22b Content-Type: text/plain; charset=UTF-8 Hi all, Recently, I've been working on a capability-based shell scripting language. The purpose of the language is to give script writers and consumers fine-grained control over what resources (files, sockets, etc) a script can access. As part of this project, we have developed a new capability-based sandbox that extends the security guarantees provided by the language to arbitrary executables. The sandbox is implemented as a policy module for the FreeBSD MAC framework. To get this to work, we needed to make a few changes to the MAC framework itself. In particular, we needed to add two new hooks: mac_vnode_post_lookup and mac_vnode_post_create. The first hook, mac_vnode_post_lookup, is inside the namei loop and provides the policy module with the vnodes and labels of both the parent node and the child, along with the componentname that was just resolved. The second hook, mac_vnode_post_create follows the various operations that invoke mac_vnode_check_create and also provides the parent and child vnodes along with the componentname. We need these hooks because our policy module simulates capability enforcement by propagating derived capabilities as files and directories are accessed or created. Our initial performance analysis indicates that these hooks introduce relatively little overhead, but we're working on more detailed benchmarks. I am curious if anyone else has implemented similar functionality for a different project or thinks that these could be useful changes to push upstream. I've attached the patch from our prototype to this email. Of course, it needs more substantial testing and additional changes to integrate it correctly with other subsystems like audit. On a related note, I'd also like to suggest a possible change to the interaction between the MAC and DAC enforcement mechanisms in the filesystem. Currently, vn_setlabel checks with the filesystem DAC before allowing a label change (by invoking VOP_ACCESS with VADMIN). For our particular use of the MAC framework this isn't ideal since our labels only restrict the current process, and this check requires the process creating the sandbox to have more privileges than it needs. It would be nice if our policy could use the privilege mechanism to overrule the DAC check in this function. I haven't worked on a patch to do this yet. Thanks, Scott --001a11332c8ea872e904ffd3b22b Content-Type: application/octet-stream; name="hooks.patch" Content-Disposition: attachment; filename="hooks.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hyg9crzb0 RnJvbSAyNzY5YTBhMGZmNDRjYzA2MTM2ZjlhMWRiYjRkYzhhNzQwMWRmY2QwIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBTY290dCBNb29yZSA8c2Rtb29yZUBmYXMuaGFydmFyZC5lZHU+ CkRhdGU6IFRodSwgMTYgSmFuIDIwMTQgMTc6MzE6NDAgLTA1MDAKU3ViamVjdDogW1BBVENIIDEv MV0gQWRkIG1hY19wb2xpY3kgaG9va3MgYWZ0ZXIgbG9va3VwIGFuZCBjcmVhdGUgb3BlcmF0aW9u cwoKLS0tCiBzeXMvY29tcGF0L2xpbnV4L2xpbnV4X2dldGN3ZC5jICB8ICA1ICsrKysrCiBzeXMv a2Vybi91aXBjX3VzcnJlcS5jICAgICAgICAgICB8ICAzICsrKwogc3lzL2tlcm4vdmZzX2xvb2t1 cC5jICAgICAgICAgICAgfCAgOCArKysrKysrKwogc3lzL2tlcm4vdmZzX3N5c2NhbGxzLmMgICAg ICAgICAgfCAzMSArKysrKysrKysrKysrKysrKysrKysrKysrKysrLS0tCiBzeXMva2Vybi92ZnNf dm5vcHMuYyAgICAgICAgICAgICB8ICA0ICsrKysKIHN5cy9zZWN1cml0eS9tYWMvbWFjX2ZyYW1l d29yay5oIHwgIDUgKysrKysKIHN5cy9zZWN1cml0eS9tYWMvbWFjX3BvbGljeS5oICAgIHwgMTAg KysrKysrKysrKwogc3lzL3NlY3VyaXR5L21hYy9tYWNfdmZzLmMgICAgICAgfCAzOSArKysrKysr KysrKysrKysrKysrKysrKysrKysrLS0tLS0tLS0tLS0KIDggZmlsZXMgY2hhbmdlZCwgOTEgaW5z ZXJ0aW9ucygrKSwgMTQgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvc3lzL2NvbXBhdC9saW51 eC9saW51eF9nZXRjd2QuYyBiL3N5cy9jb21wYXQvbGludXgvbGludXhfZ2V0Y3dkLmMKaW5kZXgg Y2FkNWEyMi4uYjE1YWViMCAxMDA2NDQKLS0tIGEvc3lzL2NvbXBhdC9saW51eC9saW51eF9nZXRj d2QuYworKysgYi9zeXMvY29tcGF0L2xpbnV4L2xpbnV4X2dldGN3ZC5jCkBAIC0xNjYsNiArMTY2 LDExIEBAIGxpbnV4X2dldGN3ZF9zY2FuZGlyKGx2cHAsIHV2cHAsIGJwcCwgYnVmcCwgdGQpCiAJ aWYgKGVycm9yID09IDApCiAjZW5kaWYKIAkJZXJyb3IgPSBWT1BfTE9PS1VQKGx2cCwgdXZwcCwg JmNuKTsKKyNpZmRlZiBNQUMKKwlpZiAoIWVycm9yKSB7CisJICBtYWNfdm5vZGVfcG9zdF9sb29r dXAodGQtPnRkX3VjcmVkLCBsdnAsICZjbiwgKnV2cHApOworCX0KKyNlbmRpZiAvKiBNQUMgKi8K IAlpZiAoZXJyb3IpIHsKIAkJdnB1dChsdnApOwogCQkqbHZwcCA9IE5VTEw7CmRpZmYgLS1naXQg YS9zeXMva2Vybi91aXBjX3VzcnJlcS5jIGIvc3lzL2tlcm4vdWlwY191c3JyZXEuYwppbmRleCA2 OWNlNGY4Li40MDI0ODlkIDEwMDY0NAotLS0gYS9zeXMva2Vybi91aXBjX3VzcnJlcS5jCisrKyBi L3N5cy9rZXJuL3VpcGNfdXNycmVxLmMKQEAgLTUzNyw2ICs1MzcsOSBAQCByZXN0YXJ0OgogCQl2 bl9maW5pc2hlZF93cml0ZShtcCk7CiAJCWdvdG8gZXJyb3I7CiAJfQorI2lmZGVmIE1BQworCW1h Y192bm9kZV9wb3N0X2NyZWF0ZSh0ZC0+dGRfdWNyZWQsIG5kLm5pX2R2cCwgbmQubmlfdnAsICZu ZC5uaV9jbmQsICZ2YXR0cik7CisjZW5kaWYKIAl2cCA9IG5kLm5pX3ZwOwogCUFTU0VSVF9WT1Bf RUxPQ0tFRCh2cCwgInVpcGNfYmluZCIpOwogCXNvdW4gPSAoc3RydWN0IHNvY2thZGRyX3VuICop c29kdXBzb2NrYWRkcihuYW0sIE1fV0FJVE9LKTsKZGlmZiAtLWdpdCBhL3N5cy9rZXJuL3Zmc19s b29rdXAuYyBiL3N5cy9rZXJuL3Zmc19sb29rdXAuYwppbmRleCA3N2RlYTgxLi42NjFhYjBmIDEw MDY0NAotLS0gYS9zeXMva2Vybi92ZnNfbG9va3VwLmMKKysrIGIvc3lzL2tlcm4vdmZzX2xvb2t1 cC5jCkBAIC03ODQsNiArNzg0LDE0IEBAIHVuaW9ubG9va3VwOgogCQlnb3RvIHN1Y2Nlc3M7CiAJ fSBlbHNlCiAJCWNucC0+Y25fbGtmbGFncyA9IGxrZmxhZ3Nfc2F2ZTsKKworI2lmZGVmIE1BQwor CWlmICgoY25wLT5jbl9mbGFncyAmIE5PTUFDQ0hFQ0spID09IDApIHsKKwkJbWFjX3Zub2RlX3Bv c3RfbG9va3VwKGNucC0+Y25fdGhyZWFkLT50ZF91Y3JlZCwgZHAsCisJCQkJICAgICAgY25wLCBu ZHAtPm5pX3ZwKTsKKwl9CisjZW5kaWYKKwogI2lmZGVmIE5BTUVJX0RJQUdOT1NUSUMKIAlwcmlu dGYoImZvdW5kXG4iKTsKICNlbmRpZgpkaWZmIC0tZ2l0IGEvc3lzL2tlcm4vdmZzX3N5c2NhbGxz LmMgYi9zeXMva2Vybi92ZnNfc3lzY2FsbHMuYwppbmRleCBjNjU5OTk4Li5mZWVmODViIDEwMDY0 NAotLS0gYS9zeXMva2Vybi92ZnNfc3lzY2FsbHMuYworKysgYi9zeXMva2Vybi92ZnNfc3lzY2Fs bHMuYwpAQCAtMTQxOCw4ICsxNDE4LDE0IEBAIHJlc3RhcnQ6CiAJCWVsc2UgewogCQkJZXJyb3Ig PSBWT1BfTUtOT0QobmQubmlfZHZwLCAmbmQubmlfdnAsCiAJCQkJCQkmbmQubmlfY25kLCAmdmF0 dHIpOwotCQkJaWYgKGVycm9yID09IDApCisJCQlpZiAoZXJyb3IgPT0gMCkgewogCQkJCXZwdXQo bmQubmlfdnApOworI2lmZGVmIE1BQworCQkJCW1hY192bm9kZV9wb3N0X2NyZWF0ZSh0ZC0+dGRf dWNyZWQsCisJCQkJCQkgICAgICBuZC5uaV9kdnAsIG5kLm5pX3ZwLAorCQkJCQkJICAgICAgJm5k Lm5pX2NuZCwgJnZhdHRyKTsKKyNlbmRpZgorCQkJfQogCQl9CiAJfQogCU5ERlJFRSgmbmQsIE5E Rl9PTkxZX1BOQlVGKTsKQEAgLTE1MTgsOSArMTUyNCwxNSBAQCByZXN0YXJ0OgogCQlnb3RvIG91 dDsKICNlbmRpZgogCWVycm9yID0gVk9QX01LTk9EKG5kLm5pX2R2cCwgJm5kLm5pX3ZwLCAmbmQu bmlfY25kLCAmdmF0dHIpOwotCWlmIChlcnJvciA9PSAwKQorCWlmIChlcnJvciA9PSAwKSB7CiAJ CXZwdXQobmQubmlfdnApOwogI2lmZGVmIE1BQworCQltYWNfdm5vZGVfcG9zdF9jcmVhdGUodGQt PnRkX3VjcmVkLAorCQkJCSAgICAgIG5kLm5pX2R2cCwgbmQubmlfdnAsCisJCQkJICAgICAgJm5k Lm5pX2NuZCwgJnZhdHRyKTsKKyNlbmRpZgorCX0KKyNpZmRlZiBNQUMKIG91dDoKICNlbmRpZgog CXZwdXQobmQubmlfZHZwKTsKQEAgLTE3ODAsOSArMTc5MiwxNSBAQCByZXN0YXJ0OgogCQlnb3Rv IG91dDI7CiAjZW5kaWYKIAllcnJvciA9IFZPUF9TWU1MSU5LKG5kLm5pX2R2cCwgJm5kLm5pX3Zw LCAmbmQubmlfY25kLCAmdmF0dHIsIHN5c3BhdGgpOwotCWlmIChlcnJvciA9PSAwKQorCWlmIChl cnJvciA9PSAwKSB7CiAJCXZwdXQobmQubmlfdnApOwogI2lmZGVmIE1BQworCQltYWNfdm5vZGVf cG9zdF9jcmVhdGUodGQtPnRkX3VjcmVkLAorCQkJCSAgICAgIG5kLm5pX2R2cCwgbmQubmlfdnAs CisJCQkJICAgICAgJm5kLm5pX2NuZCwgJnZhdHRyKTsKKyNlbmRpZgorCX0KKyNpZmRlZiBNQUMK IG91dDI6CiAjZW5kaWYKIAlOREZSRUUoJm5kLCBOREZfT05MWV9QTkJVRik7CkBAIC0zODU4LDYg KzM4NzYsMTMgQEAgcmVzdGFydDoKICNlbmRpZgogCWVycm9yID0gVk9QX01LRElSKG5kLm5pX2R2 cCwgJm5kLm5pX3ZwLCAmbmQubmlfY25kLCAmdmF0dHIpOwogI2lmZGVmIE1BQworCWlmIChlcnJv ciA9PSAwKSB7CisJCW1hY192bm9kZV9wb3N0X2NyZWF0ZSh0ZC0+dGRfdWNyZWQsCisJCQkJICAg ICAgbmQubmlfZHZwLCBuZC5uaV92cCwKKwkJCQkgICAgICAmbmQubmlfY25kLCAmdmF0dHIpOwor CX0KKyNlbmRpZgorI2lmZGVmIE1BQwogb3V0OgogI2VuZGlmCiAJTkRGUkVFKCZuZCwgTkRGX09O TFlfUE5CVUYpOwpkaWZmIC0tZ2l0IGEvc3lzL2tlcm4vdmZzX3Zub3BzLmMgYi9zeXMva2Vybi92 ZnNfdm5vcHMuYwppbmRleCAzZWQ5ZDFmLi4wZjU4NGJiIDEwMDY0NAotLS0gYS9zeXMva2Vybi92 ZnNfdm5vcHMuYworKysgYi9zeXMva2Vybi92ZnNfdm5vcHMuYwpAQCAtMTgwLDYgKzE4MCwxMCBA QCByZXN0YXJ0OgogCQkJCU5ERlJFRShuZHAsIE5ERl9PTkxZX1BOQlVGKTsKIAkJCQlyZXR1cm4g KGVycm9yKTsKIAkJCX0KKyNpZmRlZiBNQUMKKwkJICAgICAgICBtYWNfdm5vZGVfcG9zdF9jcmVh dGUoY3JlZCwgbmRwLT5uaV9kdnAsIG5kcC0+bmlfdnAsCisJCQkJCSAgICAgICZuZHAtPm5pX2Nu ZCwgdmFwKTsKKyNlbmRpZgogCQkJZm1vZGUgJj0gfk9fVFJVTkM7CiAJCQl2cCA9IG5kcC0+bmlf dnA7CiAJCX0gZWxzZSB7CmRpZmYgLS1naXQgYS9zeXMvc2VjdXJpdHkvbWFjL21hY19mcmFtZXdv cmsuaCBiL3N5cy9zZWN1cml0eS9tYWMvbWFjX2ZyYW1ld29yay5oCmluZGV4IDkyYWVkZWEuLjU2 YmMxNDEgMTAwNjQ0Ci0tLSBhL3N5cy9zZWN1cml0eS9tYWMvbWFjX2ZyYW1ld29yay5oCisrKyBi L3N5cy9zZWN1cml0eS9tYWMvbWFjX2ZyYW1ld29yay5oCkBAIC0zNzcsNiArMzc3LDkgQEAgaW50 CW1hY192bm9kZV9jaGVja19jaGRpcihzdHJ1Y3QgdWNyZWQgKmNyZWQsIHN0cnVjdCB2bm9kZSAq ZHZwKTsKIGludAltYWNfdm5vZGVfY2hlY2tfY2hyb290KHN0cnVjdCB1Y3JlZCAqY3JlZCwgc3Ry dWN0IHZub2RlICpkdnApOwogaW50CW1hY192bm9kZV9jaGVja19jcmVhdGUoc3RydWN0IHVjcmVk ICpjcmVkLCBzdHJ1Y3Qgdm5vZGUgKmR2cCwKIAkgICAgc3RydWN0IGNvbXBvbmVudG5hbWUgKmNu cCwgc3RydWN0IHZhdHRyICp2YXApOwordm9pZAltYWNfdm5vZGVfcG9zdF9jcmVhdGUoc3RydWN0 IHVjcmVkICpjcmVkLCBzdHJ1Y3Qgdm5vZGUgKmR2cCwKKwkJCSAgICAgIHN0cnVjdCB2bm9kZSAq dnAsIHN0cnVjdCBjb21wb25lbnRuYW1lICpjbnAsCisJCQkgICAgICBzdHJ1Y3QgdmF0dHIgKnZh cCk7CiBpbnQJbWFjX3Zub2RlX2NoZWNrX2RlbGV0ZWFjbChzdHJ1Y3QgdWNyZWQgKmNyZWQsIHN0 cnVjdCB2bm9kZSAqdnAsCiAJICAgIGFjbF90eXBlX3QgdHlwZSk7CiBpbnQJbWFjX3Zub2RlX2No ZWNrX2RlbGV0ZWV4dGF0dHIoc3RydWN0IHVjcmVkICpjcmVkLCBzdHJ1Y3Qgdm5vZGUgKnZwLApA QCAtMzkzLDYgKzM5Niw4IEBAIGludAltYWNfdm5vZGVfY2hlY2tfbGlzdGV4dGF0dHIoc3RydWN0 IHVjcmVkICpjcmVkLCBzdHJ1Y3Qgdm5vZGUgKnZwLAogCSAgICBpbnQgYXR0cm5hbWVzcGFjZSk7 CiBpbnQJbWFjX3Zub2RlX2NoZWNrX2xvb2t1cChzdHJ1Y3QgdWNyZWQgKmNyZWQsIHN0cnVjdCB2 bm9kZSAqZHZwLAogIAkgICAgc3RydWN0IGNvbXBvbmVudG5hbWUgKmNucCk7Cit2b2lkCW1hY192 bm9kZV9wb3N0X2xvb2t1cChzdHJ1Y3QgdWNyZWQgKmNyZWQsIHN0cnVjdCB2bm9kZSAqZHZwLAor IAkgICAgc3RydWN0IGNvbXBvbmVudG5hbWUgKmNucCwgc3RydWN0IHZub2RlICp2cCk7CiBpbnQJ bWFjX3Zub2RlX2NoZWNrX21tYXAoc3RydWN0IHVjcmVkICpjcmVkLCBzdHJ1Y3Qgdm5vZGUgKnZw LCBpbnQgcHJvdCwKIAkgICAgaW50IGZsYWdzKTsKIGludAltYWNfdm5vZGVfY2hlY2tfbXByb3Rl Y3Qoc3RydWN0IHVjcmVkICpjcmVkLCBzdHJ1Y3Qgdm5vZGUgKnZwLApkaWZmIC0tZ2l0IGEvc3lz L3NlY3VyaXR5L21hYy9tYWNfcG9saWN5LmggYi9zeXMvc2VjdXJpdHkvbWFjL21hY19wb2xpY3ku aAppbmRleCAwOTBkYzQwLi42ZGRjNzRlIDEwMDY0NAotLS0gYS9zeXMvc2VjdXJpdHkvbWFjL21h Y19wb2xpY3kuaAorKysgYi9zeXMvc2VjdXJpdHkvbWFjL21hY19wb2xpY3kuaApAQCAtNTU3LDYg KzU1NywxMCBAQCB0eXBlZGVmIGludAkoKm1wb192bm9kZV9jaGVja19jaHJvb3RfdCkoc3RydWN0 IHVjcmVkICpjcmVkLAogdHlwZWRlZiBpbnQJKCptcG9fdm5vZGVfY2hlY2tfY3JlYXRlX3QpKHN0 cnVjdCB1Y3JlZCAqY3JlZCwKIAkJICAgIHN0cnVjdCB2bm9kZSAqZHZwLCBzdHJ1Y3QgbGFiZWwg KmR2cGxhYmVsLAogCQkgICAgc3RydWN0IGNvbXBvbmVudG5hbWUgKmNucCwgc3RydWN0IHZhdHRy ICp2YXApOwordHlwZWRlZiB2b2lkICAgICgqbXBvX3Zub2RlX3Bvc3RfY3JlYXRlX3QpKHN0cnVj dCB1Y3JlZCAqY3JlZCwKKwkJICAgIHN0cnVjdCB2bm9kZSAqZHZwLCBzdHJ1Y3QgbGFiZWwgKmR2 cGxhYmVsLAorCQkgICAgc3RydWN0IHZub2RlICp2cCwgc3RydWN0IGxhYmVsICp2cGxhYmVsLAor CQkgICAgc3RydWN0IGNvbXBvbmVudG5hbWUgKmNucCwgc3RydWN0IHZhdHRyICp2YXApOwogdHlw ZWRlZiBpbnQJKCptcG9fdm5vZGVfY2hlY2tfZGVsZXRlYWNsX3QpKHN0cnVjdCB1Y3JlZCAqY3Jl ZCwKIAkJICAgIHN0cnVjdCB2bm9kZSAqdnAsIHN0cnVjdCBsYWJlbCAqdnBsYWJlbCwKIAkJICAg IGFjbF90eXBlX3QgdHlwZSk7CkBAIC01ODIsNiArNTg2LDEwIEBAIHR5cGVkZWYgaW50CSgqbXBv X3Zub2RlX2NoZWNrX2xpc3RleHRhdHRyX3QpKHN0cnVjdCB1Y3JlZCAqY3JlZCwKIHR5cGVkZWYg aW50CSgqbXBvX3Zub2RlX2NoZWNrX2xvb2t1cF90KShzdHJ1Y3QgdWNyZWQgKmNyZWQsCiAJCSAg ICBzdHJ1Y3Qgdm5vZGUgKmR2cCwgc3RydWN0IGxhYmVsICpkdnBsYWJlbCwKIAkJICAgIHN0cnVj dCBjb21wb25lbnRuYW1lICpjbnApOwordHlwZWRlZiB2b2lkCSgqbXBvX3Zub2RlX3Bvc3RfbG9v a3VwX3QpKHN0cnVjdCB1Y3JlZCAqY3JlZCwKKwkJICAgIHN0cnVjdCB2bm9kZSAqZHZwLCBzdHJ1 Y3QgbGFiZWwgKmR2cGxhYmVsLAorCQkgICAgc3RydWN0IGNvbXBvbmVudG5hbWUgKmNucCwgc3Ry dWN0IHZub2RlICp2cCwKKwkJICAgIHN0cnVjdCBsYWJlbCAqdnBsYWJlbCk7CiB0eXBlZGVmIGlu dAkoKm1wb192bm9kZV9jaGVja19tbWFwX3QpKHN0cnVjdCB1Y3JlZCAqY3JlZCwKIAkJICAgIHN0 cnVjdCB2bm9kZSAqdnAsIHN0cnVjdCBsYWJlbCAqbGFiZWwsIGludCBwcm90LAogCQkgICAgaW50 IGZsYWdzKTsKQEAgLTkxOSw2ICs5MjcsNyBAQCBzdHJ1Y3QgbWFjX3BvbGljeV9vcHMgewogCW1w b192bm9kZV9jaGVja19jaGRpcl90CQkJbXBvX3Zub2RlX2NoZWNrX2NoZGlyOwogCW1wb192bm9k ZV9jaGVja19jaHJvb3RfdAkJbXBvX3Zub2RlX2NoZWNrX2Nocm9vdDsKIAltcG9fdm5vZGVfY2hl Y2tfY3JlYXRlX3QJCW1wb192bm9kZV9jaGVja19jcmVhdGU7CisJbXBvX3Zub2RlX3Bvc3RfY3Jl YXRlX3QJCQltcG9fdm5vZGVfcG9zdF9jcmVhdGU7CiAJbXBvX3Zub2RlX2NoZWNrX2RlbGV0ZWFj bF90CQltcG9fdm5vZGVfY2hlY2tfZGVsZXRlYWNsOwogCW1wb192bm9kZV9jaGVja19kZWxldGVl eHRhdHRyX3QJCW1wb192bm9kZV9jaGVja19kZWxldGVleHRhdHRyOwogCW1wb192bm9kZV9jaGVj a19leGVjX3QJCQltcG9fdm5vZGVfY2hlY2tfZXhlYzsKQEAgLTkyNyw2ICs5MzYsNyBAQCBzdHJ1 Y3QgbWFjX3BvbGljeV9vcHMgewogCW1wb192bm9kZV9jaGVja19saW5rX3QJCQltcG9fdm5vZGVf Y2hlY2tfbGluazsKIAltcG9fdm5vZGVfY2hlY2tfbGlzdGV4dGF0dHJfdAkJbXBvX3Zub2RlX2No ZWNrX2xpc3RleHRhdHRyOwogCW1wb192bm9kZV9jaGVja19sb29rdXBfdAkJbXBvX3Zub2RlX2No ZWNrX2xvb2t1cDsKKwltcG9fdm5vZGVfcG9zdF9sb29rdXBfdAkJCW1wb192bm9kZV9wb3N0X2xv b2t1cDsKIAltcG9fdm5vZGVfY2hlY2tfbW1hcF90CQkJbXBvX3Zub2RlX2NoZWNrX21tYXA7CiAJ bXBvX3Zub2RlX2NoZWNrX21tYXBfZG93bmdyYWRlX3QJbXBvX3Zub2RlX2NoZWNrX21tYXBfZG93 bmdyYWRlOwogCW1wb192bm9kZV9jaGVja19tcHJvdGVjdF90CQltcG9fdm5vZGVfY2hlY2tfbXBy b3RlY3Q7CmRpZmYgLS1naXQgYS9zeXMvc2VjdXJpdHkvbWFjL21hY192ZnMuYyBiL3N5cy9zZWN1 cml0eS9tYWMvbWFjX3Zmcy5jCmluZGV4IGM0ZjMwNWIuLmY3YzQxYmQgMTAwNjQ0Ci0tLSBhL3N5 cy9zZWN1cml0eS9tYWMvbWFjX3Zmcy5jCisrKyBiL3N5cy9zZWN1cml0eS9tYWMvbWFjX3Zmcy5j CkBAIC00MzUsNiArNDM1LDIxIEBAIG1hY192bm9kZV9jaGVja19jcmVhdGUoc3RydWN0IHVjcmVk ICpjcmVkLCBzdHJ1Y3Qgdm5vZGUgKmR2cCwKIAlyZXR1cm4gKGVycm9yKTsKIH0KIAordm9pZAor bWFjX3Zub2RlX3Bvc3RfY3JlYXRlKHN0cnVjdCB1Y3JlZCAqY3JlZCwgc3RydWN0IHZub2RlICpk dnAsIHN0cnVjdCB2bm9kZSAqdnAsCisgICAgc3RydWN0IGNvbXBvbmVudG5hbWUgKmNucCwgc3Ry dWN0IHZhdHRyICp2YXApCit7CisJQVNTRVJUX1ZPUF9MT0NLRUQoZHZwLCAibWFjX3Zub2RlX3Bv c3RfY3JlYXRlIik7CisJQVNTRVJUX1ZPUF9MT0NLRUQodnAsICJtYWNfdm5vZGVfcG9zdF9jcmVh dGUiKTsKKworCU1BQ19QT0xJQ1lfUEVSRk9STSh2bm9kZV9wb3N0X2NyZWF0ZSwgY3JlZCwKKwkJ CSAgIGR2cCwgZHZwLT52X2xhYmVsLAorCQkJICAgdnAsIHZwLT52X2xhYmVsLAorCQkJICAgY25w LCB2YXApOworCisJcmV0dXJuOworfQorCiBNQUNfQ0hFQ0tfUFJPQkVfREVGSU5FMyh2bm9kZV9j aGVja19kZWxldGVhY2wsICJzdHJ1Y3QgdWNyZWQgKiIsCiAgICAgInN0cnVjdCB2bm9kZSAqIiwg ImFjbF90eXBlX3QiKTsKIApAQCAtNTc5LDUgKzU5NCwxOCBAQCBtYWNfdm5vZGVfY2hlY2tfbG9v a3VwKHN0cnVjdCB1Y3JlZCAqY3JlZCwgc3RydWN0IHZub2RlICpkdnAsCiAJcmV0dXJuIChlcnJv cik7CiB9CiAKK3ZvaWQKK21hY192bm9kZV9wb3N0X2xvb2t1cChzdHJ1Y3QgdWNyZWQgKmNyZWQs IHN0cnVjdCB2bm9kZSAqZHZwLAorCQkgICAgICBzdHJ1Y3QgY29tcG9uZW50bmFtZSAqY25wLCBz dHJ1Y3Qgdm5vZGUgKnZwKQoreworCUFTU0VSVF9WT1BfTE9DS0VEKGR2cCwgIm1hY192bm9kZV9w b3N0X2xvb2t1cCIpOworCUFTU0VSVF9WT1BfTE9DS0VEKHZwLCAibWFjX3Zub2RlX3Bvc3RfbG9v a3VwIik7CisKKwlNQUNfUE9MSUNZX1BFUkZPUk0odm5vZGVfcG9zdF9sb29rdXAsIGNyZWQsIGR2 cCwgZHZwLT52X2xhYmVsLCBjbnAsCisJCQkgICB2cCwgdnAtPnZfbGFiZWwpOworCisJcmV0dXJu OworfQorCiBNQUNfQ0hFQ0tfUFJPQkVfREVGSU5FNCh2bm9kZV9jaGVja19tbWFwLCAic3RydWN0 IHVjcmVkICoiLCAic3RydWN0IHZub2RlICoiLAogICAgICJpbnQiLCAiaW50Iik7Cg== --001a11332c8ea872e904ffd3b22b-- From owner-freebsd-arch@FreeBSD.ORG Mon Aug 4 21:04:03 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 176FB5D1; Mon, 4 Aug 2014 21:04:03 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E24B72990; Mon, 4 Aug 2014 21:04:02 +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 s74L41qj007792 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Aug 2014 14:04:02 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s74L40Ed007791; Mon, 4 Aug 2014 14:04:00 -0700 (PDT) (envelope-from jmg) Date: Mon, 4 Aug 2014 14:04:00 -0700 From: John-Mark Gurney To: Phil Shafer Subject: Re: XML Output: libxo - provide single API to output TXT, XML, JSON and HTML Message-ID: <20140804210400.GG88623@funkthat.com> Mail-Followup-To: Phil Shafer , Poul-Henning Kamp , "Simon J. Gerraty" , arch@freebsd.org, marcel@freebsd.org References: <63132.1406924887@critter.freebsd.dk> <201408041449.s74Emwk0019816@idle.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201408041449.s74Emwk0019816@idle.juniper.net> 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-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Mon, 04 Aug 2014 14:04:02 -0700 (PDT) Cc: arch@freebsd.org, Poul-Henning Kamp , marcel@freebsd.org, "Simon J. Gerraty" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 21:04:03 -0000 Phil Shafer wrote this message on Mon, Aug 04, 2014 at 10:48 -0400: > Poul-Henning Kamp writes: > >First of, this is not just ENOMEM, this is also invalid UTF-8 strings, > >NULL pointers and much more bogosity. > > Yup, there are 26 failure cases at present, ranging from missing > close braces in format strings to unbalanced open/close calls. > > >>Seeing broken output is better than limping > >>along with output that looks right but isn't. > >The output should preferably be explicitly broken, so that nobody > >downstream mistakenly takes it and runs with it. > > I think we're in agreement, but there is the question of what > constitutes sufficient problems to trigger abort. I'm coding the > UTF-8 support now and that's a perfect example. If the output > character set (the user's LANG setting) doesn't support a character > of output (u+10d6), does that constitute a complete failure? I'll It depends... For output to terminal/text, then you should use iconv's ICONV_SET_TRANSLITERATE option (see iconvctl(3), which isn't linked from iconv(3), but now is)... > assumably give flags to tailor the behavior, but by default, I'd > be upset if character conversion issues like this turned into > complete failure. But a format string with an invalid UTF-8 sequence > would be more severe. > > FWIW, the UTF-8 strategy for libox is this: > - all format strings are UTF-8 > - argument strings (%s) are UTF-8 > - "%ls" handles wide characters > - "%hs" will handle locale-based strings > - XML, JSON, and HTML will be UTF-8 output > - text will be locale-based This looks exactly what I had in mind... Though for XML and HTML, you might want to add the proper processing directive that says the encoding is UTF-8... How about make this an option to turn off? That way if someone wants to nest the output in another document, they provide the option to turn it off, while by default you end up w/ a properly formed HTML or XML document? > The painful part is that I've been using vsnprintf as the plumbing > for formatting strings, but it doesn't handle field widths for UTF-8 > data correctly, so I'll need to start doing that by handle myself. iconv or another i18n library should help w/ that... Since some languages, like Thai, have combining characters, so even though there might be a 6 character UTF-8 sequence, it'll only take up one column width... -- 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 Mon Aug 4 21:53:46 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 205FA75D; Mon, 4 Aug 2014 21:53:46 +0000 (UTC) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 83B3E20F7; Mon, 4 Aug 2014 21:53:45 +0000 (UTC) Received: by mail-wg0-f43.google.com with SMTP id l18so58953wgh.2 for ; Mon, 04 Aug 2014 14:53:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-type:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=qqhFUNbxfJ8w9GqMZSfDNUbPo9/O/e8DHRN/QkXi6Cg=; b=wv8BOngF4hXlOuVnNT+zO9NkvoeRpixv0THhEhqlZd7D9cnTSrky6J4IOMOv4z/wI1 fAqTUBiXl7UvnArfCgjLw76viMe5KbnMLzYVXry9C+PYCimAZSCxPcM80oR5RtDix0UB uYFn5vb1KfPBthc6adHvNEBYNydmMgQox1DnGh95b2OWWI/+9gisHr3TKOP5DQw9YHeh /ivzSSLTA+TVJYbjxf4duaFR1qpqbi5ZHz2y+qpFoZR6/tVpCsJESIpx6DB4bW9KLEoP 5tDY75jDMoEELbCzYHC2WQ2kIHzOZZhe2FHvIbTsmgnLqt0nO7U/ASbS8b5g3Xqm9cEe Sr6w== X-Received: by 10.180.93.8 with SMTP id cq8mr511578wib.17.1407189223807; Mon, 04 Aug 2014 14:53:43 -0700 (PDT) Received: from pc5.home (adhg143.neoplus.adsl.tpnet.pl. [79.184.162.143]) by mx.google.com with ESMTPSA id o2sm1006023wij.24.2014.08.04.14.53.42 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 Aug 2014 14:53:43 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Mon, 4 Aug 2014 23:53:49 +0200 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= To: Rick Macklem Subject: Re: [CFT] Autofs. Message-ID: <20140804215349.GA33526@pc5.home> Mail-Followup-To: Rick Macklem , "Bjoern A. Zeeb" , freebsd-current@FreeBSD.org, freebsd-arch@FreeBSD.org References: <3DA39B51-4CE5-437B-9B03-7E34CC954A7E@lists.zabbadoz.net> <1593472917.6916985.1407178271363.JavaMail.root@uoguelph.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1593472917.6916985.1407178271363.JavaMail.root@uoguelph.ca> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "Bjoern A. Zeeb" , freebsd-current@FreeBSD.org, freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 21:53:46 -0000 On 0804T1451, Rick Macklem wrote: > Bjoern A. Zeeb wrote: > > On 30 Jul 2014, at 07:19 , Edward Tomasz Napierała > > wrote: > > > > > At the link below you will find a patch that adds the new > > > automounter. > > > The patch is against yesterdays 11.0-CURRENT. > > > > > > http://people.freebsd.org/~trasz/autofs-head-20140729.diff > > > > I also just submitted > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192379 to allow -o > > vers= mount_nfs compatibility, which makes it easier to integrate > > with Linux/OSX/Solaris LDAP setups and mount options from LDAP. > > > > > > > Testing is welcome. Please start with manual pages, eg. > > > automount(8). > > > > > > I found one case now doing the aforementioned where when the initial > > mount_nfs fails (e.g., for invalid options), then a later mount did > > not succeed either, with the correct mount options; I did try to > > run automount -u in between tries, as well as service automountd > > restart, but that did not make a change; given I was short on time, > > a reboot of my desktop made this go away. Is there some “negative > > caching” in the kernel module possibly that will not retry the mount > > for another time or something—as in if I were more patient and > > waited 5 minutes, would it maybe just have worked again? > > > If I recall it correctly, it retries a mount attempt that fails after > something like 1min (which seems like a long time when you are waiting > for it;-). I think that was done so that clients don't flood a rebooting > server with mount attempts, but that code was written long, long ago. >From what I've seen mount_nfs(8) retries indefinitely; that's why automountd disables that behaviour by default, by passing "retrycnt=1". From owner-freebsd-arch@FreeBSD.ORG Mon Aug 4 21:56:44 2014 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F004F9F9; Mon, 4 Aug 2014 21:56:44 +0000 (UTC) Received: from mx1.stack.nl (relay04.stack.nl [IPv6:2001:610:1108:5010::107]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mailhost.stack.nl", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B39BE211E; Mon, 4 Aug 2014 21:56:44 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 07773B8057; Mon, 4 Aug 2014 23:56:42 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 1677) id E8EC028497; Mon, 4 Aug 2014 23:56:41 +0200 (CEST) Date: Mon, 4 Aug 2014 23:56:41 +0200 From: Jilles Tjoelker To: Baptiste Daroussin Subject: Re: Add ohash (OpenBSD hash) into libutil Message-ID: <20140804215641.GA80850@stack.nl> References: <20140727230110.GI50802@ivaldir.etoilebsd.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140727230110.GI50802@ivaldir.etoilebsd.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: arch@FreeBSD.org, hackers@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 21:56:45 -0000 On Mon, Jul 28, 2014 at 01:01:10AM +0200, Baptiste Daroussin wrote: > If noone objects I would like to bring ohash from OpenBSD into our > libutil. > Ohash is already in base (usr.bin/m4/ohash) having it into libutil > will increase compatibility with OpenBSD as well as allowing the rest > of the base system to be able to benefit from ohash implementation. Following OpenBSD's general low priority for binary compatibility issues, the functions have the application allocate struct ohash. For use in a symbol-versioned library that promises backwards compatibility, it would be better to leave the type incomplete in the public header and have the library allocate it. Adding these functions encourages using open addressing (no chaining) because that's what's available. This may be OK but it might be bad in specific situations. The automatic resizing of the hash table, absent in many home-grown hash table implementations, may help avoid such problems somewhat. The code in ohash_resize() that may set the hash table size to UINT_MAX violates the requirement that the probe interval (incr) must be relative prime to the hash table size (otherwise ohash_lookup_interval() might loop indefinitely examining only a subset of the table, while the rest of the table still has free space). Normally, the code enforces this requirement by making the hash table size a power of two and the probe interval an odd number. On another note, if the hash table size is always a power of two, the slow hv % h->size can be replaced by hv & (h->size - 1). The incr should probably only be calculated when needed, or using a method that does not involve dividing by a variable. (Note that hv doesn't contain sufficient bits for an independent i and hv if the hash table is larger than 65536 entries, so such large hash tables will be used less uniformly.) Utilities that value startup and fork performance (such as sh(1)) do not want to depend on additional DSOs (why is libutil separate from libc?). -- Jilles Tjoelker From owner-freebsd-arch@FreeBSD.ORG Sat Aug 9 15:53:46 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 38F8380A for ; Sat, 9 Aug 2014 15:53:46 +0000 (UTC) Received: from mail-qc0-x22d.google.com (mail-qc0-x22d.google.com [IPv6:2607:f8b0:400d:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F410729C1 for ; Sat, 9 Aug 2014 15:53:45 +0000 (UTC) Received: by mail-qc0-f173.google.com with SMTP id w7so333220qcr.18 for ; Sat, 09 Aug 2014 08:53:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=ANgPtVZhGquGy+muTEacS/DVjfmqmIk7lAmf2sYBf+4=; b=wS0Cl09Wl0ftuPt3xYtmGoKIVd9EcIDA3Pvb7ut6dtbZtr5ZT0k0P80EajeT3T38rY bY2O3IEypL/uxMqa6EjUHk4mc273UssXlb9Yts5vb1pQLeX5ftJf/xNKDUXVvR/o0SgS nOJAvsHP7ArvtVhtvC3qaVI5dHh5xaNtqHWbWnz0Ehev13lljWjhoSNOYAd6xxl3WZPT kUEJ8hGwBfb/269QYJ/RFO7v2QTTf4Q8ODjfyrSIiKKloyMqiY+pDadEFRyZsQZHLqck k/ycWzH2U9VCjdeehVeIx6DJgW1eh6YHmBzC2eF6ERMib9qIqoQydqMQipz+E2ZOZWpd Tu8A== MIME-Version: 1.0 X-Received: by 10.224.156.145 with SMTP id x17mr32575617qaw.49.1407599624987; Sat, 09 Aug 2014 08:53:44 -0700 (PDT) Received: by 10.224.41.6 with HTTP; Sat, 9 Aug 2014 08:53:44 -0700 (PDT) Date: Sat, 9 Aug 2014 08:53:44 -0700 Message-ID: Subject: RFC: cpuid_t From: Adrian Chadd To: "freebsd-arch@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Aug 2014 15:53:46 -0000 Hi, How's this look? Index: sys/sys/_types.h =================================================================== --- sys/sys/_types.h (revision 269480) +++ sys/sys/_types.h (working copy) @@ -52,6 +52,7 @@ typedef __uint16_t __nlink_t; /* link count */ typedef __int64_t __off_t; /* file offset */ typedef __int32_t __pid_t; /* process [group] */ +typedef __uint32_t __cpuid_t; /* CPU ID */ typedef __int64_t __rlim_t; /* resource limit - intentionally */ /* signed, because of legacy code */ /* that uses -1 for RLIM_INFINITY */ Index: sys/sys/types.h =================================================================== --- sys/sys/types.h (revision 269480) +++ sys/sys/types.h (working copy) @@ -154,6 +154,11 @@ #define _LWPID_T_DECLARED #endif +#ifndef _CPUID_T_DECLARED +typedef __cpuid_t cpuid_t; /* CPU ID */ +#define _CPUID_T_DECLARED +#endif + #ifndef _MODE_T_DECLARED typedef __mode_t mode_t; /* permissions */ #define _MODE_T_DECLARED -a From owner-freebsd-arch@FreeBSD.ORG Sat Aug 9 21:16:36 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 310E7BE9 for ; Sat, 9 Aug 2014 21:16:36 +0000 (UTC) Received: from mail105.syd.optusnet.com.au (mail105.syd.optusnet.com.au [211.29.132.249]) by mx1.freebsd.org (Postfix) with ESMTP id D24612936 for ; Sat, 9 Aug 2014 21:16:35 +0000 (UTC) Received: from c122-106-147-133.carlnfd1.nsw.optusnet.com.au (c122-106-147-133.carlnfd1.nsw.optusnet.com.au [122.106.147.133]) by mail105.syd.optusnet.com.au (Postfix) with ESMTPS id 727C11042589; Sun, 10 Aug 2014 07:16:27 +1000 (EST) Date: Sun, 10 Aug 2014 07:16:26 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Adrian Chadd Subject: Re: RFC: cpuid_t In-Reply-To: Message-ID: <20140810060747.V855@besplex.bde.org> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=BdjhjNd2 c=1 sm=1 tr=0 a=7NqvjVvQucbO2RlWB8PEog==:117 a=PO7r1zJSAAAA:8 a=kj9zAlcOel0A:10 a=JzwRw_2MAAAA:8 a=3furF_ONEQf7hv0KB04A:9 a=5P0jsJUho5o3cfS9:21 a=e-O3tETWo9o0U7ya:21 a=CjuIK1q_8ugA:10 Cc: "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Aug 2014 21:16:36 -0000 On Sat, 9 Aug 2014, Adrian Chadd wrote: > How's this look? Not good. > Index: sys/sys/_types.h > =================================================================== > --- sys/sys/_types.h (revision 269480) > +++ sys/sys/_types.h (working copy) > @@ -52,6 +52,7 @@ > typedef __uint16_t __nlink_t; /* link count */ > typedef __int64_t __off_t; /* file offset */ > typedef __int32_t __pid_t; /* process [group] */ > +typedef __uint32_t __cpuid_t; /* CPU ID */ > typedef __int64_t __rlim_t; /* resource limit - intentionally */ > /* signed, because of legacy code */ > /* that uses -1 for RLIM_INFINITY */ Unsorting. In the English alphabet, c is not between p and r. The whitespace seems to be inconsistent, but the mail corrupted all the tabs so it is hard to tell. > Index: sys/sys/types.h > =================================================================== > --- sys/sys/types.h (revision 269480) > +++ sys/sys/types.h (working copy) > @@ -154,6 +154,11 @@ > #define _LWPID_T_DECLARED > #endif > > +#ifndef _CPUID_T_DECLARED > +typedef __cpuid_t cpuid_t; /* CPU ID */ > +#define _CPUID_T_DECLARED > +#endif > + > #ifndef _MODE_T_DECLARED > typedef __mode_t mode_t; /* permissions */ > #define _MODE_T_DECLARED Unsorting. c is also not between l and m. The comment is banal, like many nearby ones. It does less than echo the code. Most for ids at least echo the code by repeating "id" in lower case. In private mail, I said that this typedef is less needed than one for file descriptors. Since the latter need is negative, the need for this one is very negative. Ids should be small integers so that they can be used directly as array indexes, unless they need to cover a large sparse namespace so that they need to be hash numbers. POSIX has far too many typedefed types. Similar mistakes were made for pid_t. It should have been plain int like the file descriptor type, but some implementations made it short and some implementations made it longer. (4.4BSD-Lite1 even made it long on all arches, but that was a larger mistake since it gives a very long type on 64-bit arches and using the same underlying type on all arches loses the only advantage of the typedef -- that its ABI doesn't depend on the underlying types. It was changed to int32_t in NetBSD. Lite2 picked up this change, and FreeBSD picked up the change from Lite2. Changing it back and forth mainly exposed brokenness in printf formats for it (many new ones are broken again, since they assume that pid_t promotes to int). Changing it would have broken the ABI for 64-bit arches, but FreeBSD had only tier {PID_MAX} ones at the time. NetBSD had higher(numerically lower) ones, so it had to be more careful with ABIs. It changed many other longs back down to ints spelled as int32_t's so that the sizes were the same as they used to be but the types were not hard-coded as int so as to defend agains future expansion of ints (hasn't happened yet, and might never happen since API and ABI assumptions that types are plain int (even when they are typedefed) are much more pervasive than similar assumptions for longs (like the one that off_t == long). POSIX had to make pid_t a typedef to support historical misimplementations where it wasn't the same. The problem never affected file descriptors since mot or all implementations always used plain int. Plain int being right for file descriptors is related to syscalls returning int. open() is a very basic syscall and it always returned int. pid_t's are used in not so basic syscalls, so types error from using a more complicated or different type for pids would have been less obvious. For CPU ids, the only problem seems to be that u_char is used for them. This limits their number to 255 real ones and 1 dummy one (not 128 real ones as claimed in this thread). This saves a whole 3 bytes per id in struct thread and perhaps in a few other data structures where packing is not unimportant. This is like misimplementing pid_t as u_char (except pid_t needs more than 1 dummy value since it abuses the top bit for process group ids). Most systems don't have more than 255 or even 128 CPUs or users, but some do. If int had been used from the start like it was for file descriptors, then no one would have noticed the problem of larger systems. Using anything except plain int gives minor type promotion and printing problems. Using a typedef gives more problems in theory, since if someone actually uses its for its only useful use of changing it, then code breaks unless it takes excessive care with promotion and printing. A variable type also causes ABI problems. The current u_char type is hard-coded twice in struct kinfo. So to just expand it to int32_t, you have to add new fields to struct kinfo, and maintain the old fields for old programs, and put something harmless in these fields instead of blindly overflowing for unrepresentable values. kinfo defines an ABI so it shouldn't have any typedef types in it except ones for fixed-width integers. It has many now. cpuid_t would be a new one. Then you can't simply change cpuid_t, but have to go through the expansion or contraction process for kinfo every time you change it. CPU ids seem to be used mainly as indexes in cpuid_to_cpuid[]. See pcpu_find(). If they were cookies, then they could be struct pcpu *'s and not need looking up. But that wouldn't work in user APIs like kinfo. The current use is similar to looking up file descriptors in a table. The descriptor must be a small index to work for that. Management of file descriptor tables has become very complex with bloat in the number of fds. The current maximum number of CPUs is similar to the maximum number of file descriptors on old systems. I doubt that the number of CPUs will grow as fast as the number of file descriptors. If it does, then managing the pcpu tables would be the least of the problems. Who knows how to schedule a few million CPUs? Bruce