From owner-freebsd-arch@FreeBSD.ORG Sun Jul 7 05:26:01 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 B2C62B17; Sun, 7 Jul 2013 05:26:01 +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 5200D1169; Sun, 7 Jul 2013 05:26:01 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r675Ps0r035555; Sun, 7 Jul 2013 08:25:54 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r675Ps0r035555 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r675Prid035544; Sun, 7 Jul 2013 08:25:53 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 7 Jul 2013 08:25:53 +0300 From: Konstantin Belousov To: Benno Rice Subject: Re: Reworking vmmeter Message-ID: <20130707052553.GC91021@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PN720ooTGWi/DZaq" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2013 05:26:01 -0000 --PN720ooTGWi/DZaq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jul 07, 2013 at 09:53:37AM +1000, Benno Rice wrote: > So I've put together this patch: >=20 > http://people.freebsd.org/~benno/vmmeter.diff >=20 > This patch does a few things: >=20 > - Renames the singleton "cnt" to "vmmeter". > - Replaces all the per-cpu counters with counter_u64_t. > - Removes the vmmeter instance from struct pcpu, due to the above mention= ed change. > - Adds includes for vmmeter.h to a few files that were only getting it vi= a pollution in pcpu.h > - Removes some entries from assym that weren't being used. >=20 > This has been tested on amd64 and nothing else right now, I'm more postin= g this to get general comments on whether people think this is a good idea.= My motivation for this was twofold, firstly to rename cnt and secondly to = move the counters to the common counter framework. More testing will be don= e prior to commit. >=20 Why did you removed the CTASSERT from sys/pcpu.h ? Your edits for the inlines in the sys/vmmeter.h are notoriously violating style. You probably could add some macro like COUNTER_U64_INITIALIZED(), which would check for the counter containing non-NULL pointer. At least this would allow to remove vmmeter_use_early_counters. Still the hack of early_*_faults cannot be avoided this way. Or, since BSP is guaranteed to have id 0, you could temporary put a pointer to the early_*_faults into the counter_u64_t, which is to be overwritten after the real counter is initialized. Then the if()s in the vm_fault() can be removed. Note that the parts of counters(9) KPI used in your patch has known issue on some 32 bit arches, namely powerpc32, mips32 and arm. The fetch could loose the carry bit in a cell, transiently. This is a bug in the platform implementation, and not the inherent counters(9) limitation. Fixing requires some asm magic (basically, the counter cells updates and fetches must be 64bit atomics). This is done on i386 already, and the problem does not exist on 64bit arches. --PN720ooTGWi/DZaq Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJR2PvgAAoJEJDCuSvBvK1BhZAP/RUWBuFbDdpGbOzGTIx9i9Kf oUBLy+lG+xzK2ZKWhid/D/VP01FCeZ//ANvtD0o/Y/qGUBiu+IVH/VkfLt6bj3Wz 4f82z77SuhD7iuqvkHfjm4Lc2ASFq+K8aOpZoD5xLWGk+awamzMe8xf8t4OoX3hX S0e5zrEU/qHSmB/Z4X3/0VXdC/xPtmyNESYU3Thrzy4NMdKjzBGNm7NeyMUTT8Ha XIOxIrXmvVl7maG0oH3Re1QXlT5eKRY6tr3Y0/AJBVuTg96HJu5ghF9UgmLCQavF T4dT3hhvdD96XcXN3ASXE7A2lJhHjB9+RS6WL2A6y9vy7YOIdv8YZ5VU5POaQUUx nPa/KPU6gaCJfZnZv2qwroSl16b6w/uwTRrH/oEEKMiPc8GZS0wvvDlKwqy8hq3P dVU6N2knAr3UCd085grKuszH5V8aJ9J1m0oAgh4EI53J0ctM1ViZH9gXrTWVGf3X nshngembQKboX6SsO8QsVBLOBnnVfvMF1Q9LqjvQdDN3O4+ZWuqU2DUW2Ql10XfO qiTafbgdtWUVxVgxOqXqq1yy3ieZJ9EG+8wI133R4yH1Aej57Ifjb0ZCMUA69zSr FO+taweaJPTZq6MWeH0x3D8BZgj83/PftcDZuS7EJKBjC4u8oAekYCio3YRNqant EQ4hyWfLdV3oUxLW3YEQ =lWmE -----END PGP SIGNATURE----- --PN720ooTGWi/DZaq-- From owner-freebsd-arch@FreeBSD.ORG Sun Jul 7 08:16:42 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 A1EDBB73; Sun, 7 Jul 2013 08:16:42 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail109.syd.optusnet.com.au (mail109.syd.optusnet.com.au [211.29.132.80]) by mx1.freebsd.org (Postfix) with ESMTP id E06E3193C; Sun, 7 Jul 2013 08:16:41 +0000 (UTC) Received: from c122-106-156-23.carlnfd1.nsw.optusnet.com.au (c122-106-156-23.carlnfd1.nsw.optusnet.com.au [122.106.156.23]) by mail109.syd.optusnet.com.au (Postfix) with ESMTPS id A475D123644; Sun, 7 Jul 2013 18:16:33 +1000 (EST) Date: Sun, 7 Jul 2013 18:16:32 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Konstantin Belousov Subject: Re: Reworking vmmeter In-Reply-To: <20130707052553.GC91021@kib.kiev.ua> Message-ID: <20130707173525.K4305@besplex.bde.org> References: <20130707052553.GC91021@kib.kiev.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.0 cv=K8x6hFqI c=1 sm=1 a=kj9zAlcOel0A:10 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=JfFbYrH9e9EA:10 a=6I5d2MoRAAAA:8 a=ENfZFP4TCVWULLcAm9cA:9 a=CjuIK1q_8ugA:10 a=ebeQFi2P/qHVC0Yw9JDJ4g==:117 Cc: Benno Rice , 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, 07 Jul 2013 08:16:42 -0000 On Sun, 7 Jul 2013, Konstantin Belousov wrote: > On Sun, Jul 07, 2013 at 09:53:37AM +1000, Benno Rice wrote: >> So I've put together this patch: >> >> http://people.freebsd.org/~benno/vmmeter.diff >> >> This patch does a few things: >> >> - Renames the singleton "cnt" to "vmmeter". >> - Replaces all the per-cpu counters with counter_u64_t. >> - Removes the vmmeter instance from struct pcpu, due to the above mentioned change. >> - Adds includes for vmmeter.h to a few files that were only getting it via pollution in pcpu.h >> - Removes some entries from assym that weren't being used. >> >> This has been tested on amd64 and nothing else right now, I'm more posting this to get general comments on whether people think this is a good idea. My motivation for this was twofold, firstly to rename cnt and secondly to move the counters to the common counter framework. More testing will be done prior to commit. > > Why did you removed the CTASSERT from sys/pcpu.h ? > > Your edits for the inlines in the sys/vmmeter.h are notoriously > violating style. It has some style bugs (mainly verbose names and long lines), but it is the old inlines in sys/vmmeter.h that have gross style bugs. About half of the changes are for things in struct vmmeter that aren't per-CPU counters. Too many atomic ops are needed to access these. These could be changed separately -- keep them in a struct named "cnt" until later. vm/vm_meter.c is uglier than before. The vcnt() hack was at least short. Now with sysctl support for combining the per-CPU parts, it should take less code than before if the counter API and its use were anyy good. Instead it takes 10 times as much to allocate and use all the counters separately. Older design errors for vmmeter: - there should have been a vmmeter sysctl that returns struct vmmeter - instead, there was a VM_METER sysctl that returned struct vmtotal. This andd the VM_LOADAVG were all that 4.4BSD had - FreeBSD added many little sysctls to return the things in struct vmmeter separately. This is very large and slow for both the kernel and applications. - this was unimproved further by renaming VM_METER to VM_TOTAL without preparing to use VM_METER to actually return struct vmmeter. It might have been possible to expand the VM_METER sysctl to return everything. If you change all the little sysctls to return 64-bit counters, then you will have similar API and ABI incompatibilites unless you add compatibility cruft for everything. Size changes are only slightly simpler to handle for scalar sysctls. > You probably could add some macro like COUNTER_U64_INITIALIZED(), which > would check for the counter containing non-NULL pointer. At least this > would allow to remove vmmeter_use_early_counters. Still the hack of > early_*_faults cannot be avoided this way. Or, since BSP is guaranteed > to have id 0, you could temporary put a pointer to the early_*_faults > into the counter_u64_t, which is to be overwritten after the real counter > is initialized. Then the if()s in the vm_fault() can be removed. There are also probems with late faults. v_trap is incremented in trap(), but trap() may be for an NMI interrupting an increment of v_trap. The locking ibased on disabling interrupts for updating counters doesn't work for such counters, unlike PCPU_INC() on 32-bit counters on x86 (PCPU_INC() is broken on most non-x86 arches). > Note that the parts of counters(9) KPI used in your patch has known > issue on some 32 bit arches, namely powerpc32, mips32 and arm. The fetch > could loose the carry bit in a cell, transiently. This is a bug in the > platform implementation, and not the inherent counters(9) limitation. > Fixing requires some asm magic (basically, the counter cells updates and > fetches must be 64bit atomics). This is done on i386 already, and > the problem does not exist on 64bit arches. The bug affects mainly cases that don't work at all with 32-bit counters or with the non-atomic (broken) PCPU_*() accesses on most arches except x86, but I still disagree with using 64-bit counters for the low-level counters. This is pessimal on i386 and causes even larger implemetation problems/pessimizations on non-i386 non-64-bit systems. Bruce From owner-freebsd-arch@FreeBSD.ORG Sun Jul 7 15:56:21 2013 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id F35C244C; Sun, 7 Jul 2013 15:56:20 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id BB5C11966; Sun, 7 Jul 2013 15:56:20 +0000 (UTC) Received: from critter.freebsd.dk (unknown [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id B8E783EB70; Sun, 7 Jul 2013 15:56:13 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.7/8.14.7) with ESMTP id r67FuDsH002870; Sun, 7 Jul 2013 15:56:13 GMT (envelope-from phk@phk.freebsd.dk) To: Pawel Jakub Dawidek Subject: Re: General purpose library for name/value pairs. In-reply-to: <20130706194124.GE25842@garage.freebsd.pl> From: "Poul-Henning Kamp" References: <20130704215329.GG1402@garage.freebsd.pl> <4818.1373008073@critter.freebsd.dk> <20130705195255.GB25842@garage.freebsd.pl> <60317.1373055040@critter.freebsd.dk> <20130706194124.GE25842@garage.freebsd.pl> Content-Type: text/plain; charset=ISO-8859-1 Date: Sun, 07 Jul 2013 15:56:13 +0000 Message-ID: <2869.1373212573@critter.freebsd.dk> Cc: arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2013 15:56:21 -0000 In message <20130706194124.GE25842@garage.freebsd.pl>, Pawel Jakub Dawidek writ es: >> Maybe the basic n/v should just do strings, and interpretation of >> strings be a layer above ? > >It would make getting values from the nvlist a hell - dealing with >strto* functions and checking if conversion succeeded, that just too >complex. If you look at the functionality it doesn't look that bad. >atomic(9) has the same "problem" with multiple types. Which is why I'm not too happy about atomic(9) either :-) In the end it is a deficiency in the ISO-C standardiszation lacking ambition :-/ >> You know ? Screw that! Having usable errors only in english is >> far better than having only "Invalid argument" in all the languages >> of the world. > >Well, can't we do better than that? This argument goes both ways. Indeed it does. But I don't see anyone talking about translating everything that goes into dmesg og syslog, so for now our kernel and systems functions are english only. Once somebody figures out the _method_ for handling those translations, we can start to talk about it. In the meantime, it would be a big mistake to restrict ourselves to "Invalid Argument" for complex API's -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Mon Jul 8 11:24: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 A8B38427 for ; Mon, 8 Jul 2013 11:24:39 +0000 (UTC) (envelope-from info@info-emailer.com) Received: from mail7.info-emailer.com (mail7.info-emailer.com [74.86.42.174]) by mx1.freebsd.org (Postfix) with ESMTP id 7CAD61C1C for ; Mon, 8 Jul 2013 11:24:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=key2; d=info-emailer.com; h=Date:From:To:Subject:List-Unsubscribe:MIME-Version:Content-Type:Message-ID; i=info@info-emailer.com; bh=TPX0CbcN+41YFMh1By2akrlW2K4=; b=g1QCTUQmNGIuzPo7Motj1fA443Vl6q5ybGgkWyq5sZOwTrMFlCuNjd9Y+wQ064C9gckdUiNssW9T QCM49TFmVlyU8zVp6IBS9C1mI0kCuuNrV/ANdlXq8wCmA2rVA/cxnjItPuOWOCNE8a6navJhzlg6 ivkxYqL1ImwLrGQSIUU= DomainKey-Signature: a=rsa-sha1; c=nofws; q=dns; s=key2; d=info-emailer.com; b=llCEkY1l4T40rNc7obzKvv4lu9YZ6+aVb4voTlJV+RN5TpAdTvQI8KUOIDaz4/LhbB50dKVvMYmF OKTOgMinkn+T6XmusZZld/NowsDMisG38K9WltVf/NU1b7OJsSnx8ynddn/kb+jttiozkZKrcfha iGVsYbt0PtWWcC1Ommk=; Received: by mail7.info-emailer.com (PowerMTA(TM) v3.5r14) id hragne1k2gom for ; Mon, 8 Jul 2013 03:29:17 -0500 (envelope-from ) Date: Mon, 8 Jul 2013 08:29:17 +0000 From: sunduah@gmail.com To: freebsd-arch@freebsd.org Subject: You still haven't accepted sunduah@gmail.com's friend request. Accept? X-Reference_Id: 4afbd396-d806-4d54-87c4-a339f2a6d1ea MIME-Version: 1.0 Message-ID: <0.0.252.1B1.1CE7BB53CCB5B32.1F89@mail7.info-emailer.com> Content-Type: text/plain; charset=utf-8 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, 08 Jul 2013 11:24:39 -0000 Hi, {from_name} wants to follow you. ****** Is {from_name} you friend? ****** If Yes please follow the link below: http://invites.info-emailer.com/signup_e.html?fullname=&email=freebsd-arch@freebsd.org&invitername=David&inviterid=17783022&userid=0&token=0&emailmasterid=4afbd396-d806-4d54-87c4-a339f2a6d1ea&from=sunduah@gmail.com&uie=1 If No please follow the link below: http://invites.info-emailer.com/signup_e_no.html?fullname=&email=freebsd-arch@freebsd.org&invitername=David&inviterid=17783022&userid=0&token=0&emailmasterid=4afbd396-d806-4d54-87c4-a339f2a6d1ea&from=sunduah@gmail.com&uie=1 Follow the link below to remove yourself from all such emails, http://invites.info-emailer.com/uns.jsp?email=freebsd-arch@freebsd.org&iid=4afbd396-d806-4d54-87c4-a339f2a6d1ea&from=sunduah@gmail.com From owner-freebsd-arch@FreeBSD.ORG Mon Jul 8 15:02:41 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 99540635 for ; Mon, 8 Jul 2013 15:02:41 +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 650A91796 for ; Mon, 8 Jul 2013 15:02:41 +0000 (UTC) Received: from localhost (58.wheelsystems.com [83.12.187.58]) by mail.dawidek.net (Postfix) with ESMTPSA id 986F28CF; Mon, 8 Jul 2013 16:57:56 +0200 (CEST) Date: Mon, 8 Jul 2013 17:03:08 +0200 From: Pawel Jakub Dawidek To: Poul-Henning Kamp Subject: Re: General purpose library for name/value pairs. Message-ID: <20130708150308.GE1383@garage.freebsd.pl> References: <20130704215329.GG1402@garage.freebsd.pl> <4818.1373008073@critter.freebsd.dk> <20130705195255.GB25842@garage.freebsd.pl> <60317.1373055040@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SxgehGEc6vB0cZwN" Content-Disposition: inline In-Reply-To: <60317.1373055040@critter.freebsd.dk> X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 15:02:41 -0000 --SxgehGEc6vB0cZwN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 05, 2013 at 08:10:40PM +0000, Poul-Henning Kamp wrote: > Maybe the basic n/v should just do strings, and interpretation of > strings be a layer above ? How about instead of supporting int8, uint8, int16, uint16, int32, uint32, int64 and uint64 I'd just support 'number' type, which would be uint64_t. This shouldn't break transporting signed values and because I don't support basic types like int, long, etc. casting or conversion has to be done anyway. This would reduce number of supported types to: NV_TYPE_NULL NV_TYPE_BOOL NV_TYPE_NUMBER NV_TYPE_STRING NV_TYPE_NVLIST NV_TYPE_DESCRIPTOR NV_TYPE_BOOL_ARRAY NV_TYPE_NUMBER_ARRAY NV_TYPE_STRING_ARRAY NV_TYPE_NVLIST_ARRAY NV_TYPE_DESCRIPTOR_ARRAY So 11 types down from 25 types. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://mobter.com --SxgehGEc6vB0cZwN Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iEYEARECAAYFAlHa1KwACgkQForvXbEpPzS0vACeP15MUHex5woR6unjTxJJvY1a WVIAn2TKsIXfymYPYLIPeVJ0Ua90afx9 =1tzW -----END PGP SIGNATURE----- --SxgehGEc6vB0cZwN-- From owner-freebsd-arch@FreeBSD.ORG Mon Jul 8 17:57:56 2013 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 184576DE; Mon, 8 Jul 2013 17:57:56 +0000 (UTC) (envelope-from jkh@mail.turbofuzz.com) Received: from mail.crittercasa.com (mail.turbofuzz.com [208.87.221.144]) by mx1.freebsd.org (Postfix) with ESMTP id 04C401F15; Mon, 8 Jul 2013 17:57:55 +0000 (UTC) Received: from [10.20.30.11] (75-101-82-48.static.sonic.net [75.101.82.48]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.crittercasa.com (Postfix) with ESMTPS id 28C3416487D; Mon, 8 Jul 2013 10:37:45 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1783\)) Subject: Re: General purpose library for name/value pairs. From: Jordan Hubbard In-Reply-To: <20130708150308.GE1383@garage.freebsd.pl> Date: Mon, 8 Jul 2013 10:57:17 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <717D098F-D07E-45B0-B9F0-8D8BCEF06923@mail.turbofuzz.com> References: <20130704215329.GG1402@garage.freebsd.pl> <4818.1373008073@critter.freebsd.dk> <20130705195255.GB25842@garage.freebsd.pl> <60317.1373055040@critter.freebsd.dk> <20130708150308.GE1383@garage.freebsd.pl> To: Pawel Jakub Dawidek X-Mailer: Apple Mail (2.1783) Cc: arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 17:57:56 -0000 On Jul 8, 2013, at 8:03 AM, Pawel Jakub Dawidek wrote: > How about instead of supporting int8, uint8, int16, uint16, int32, > uint32, int64 and uint64 I'd just support 'number' type, which would = be > uint64_t. This shouldn't break transporting signed values and because = I > don't support basic types like int, long, etc. casting or conversion = has > to be done anyway. This would reduce number of supported types to: That's a good idea. Since you're re-inventing Apple's XML property list = API (but without serialization and quite a few other things), keeping = the number of supported types down is much better than the converse - = exposing the details of 16/32/64 bit numbers and their signedness will = hang you over the long term, and you can always provide explicit = conversion functions to/from Number for those who actually care. String, Number, Boolean, Data, Date, Array and Dictionary are all plists = support, and Apple developers have gotten along pretty well for many = years with that set (not supporting Dictionaries, btw, is a pretty = fundamental loss IMHO - it means you have to always iterate through = lists to find your stuff, which is meh!). When Apple extended the Plist metaphor for IPC (to create XPC), they = also added out-of-band types like file and shared memory descriptors. = You have file descriptors, but not shared memory. The latter is kind of = important if you want to do larger IPCs with this mechanism someday and = want to support "big payloads" transparently without passing the burden = of the data management to the application programmer. Before you also come back with "but but this is a kernel API! For just = one purpose!" let me just say that it's absolutely achievable to have = ONE API for talking userland<->kernel and userland<->userland with the = same types and the transport mechanism(s) largely abstracted away. You = don't need two - it's already been done with one, just look next door. = :) If you add file serialization of this format to your picture (and add = the dictionary type) , bingo, now you have a preferences API that = FreeBSD has lacked from day one ("just roll your own format and stick = the file in /etc" being the canonical response to that need). - Jordan From owner-freebsd-arch@FreeBSD.ORG Mon Jul 8 18:45:56 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 583C9C91; Mon, 8 Jul 2013 18:45:56 +0000 (UTC) (envelope-from crodr001@gmail.com) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) by mx1.freebsd.org (Postfix) with ESMTP id A97C81210; Mon, 8 Jul 2013 18:45:55 +0000 (UTC) Received: by mail-la0-f46.google.com with SMTP id eg20so4131087lab.33 for ; Mon, 08 Jul 2013 11:45:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=vLMXrk3QdYQ8R336igSptN3Gy5oOwFwr3SmBqTrdPSA=; b=y/VXovr7ip1w13u7AfcLoU+KpdfzzOoojQ1+kZSalt/KuD8dGFqzVxaXmjfqRc+DNa imFSRpRBznX9OocurQVpFUBLcmleZrEbDcxJ9LotCkqIb1W00/Bce6QY8/zhvLPW7uNe RouTTi+UhS0BcaLOTPm3d3t3xX4U+/+O37RaEPQVDzagxUj+geouPn+W5mTf2XO3Ol9J E7GybjU/Lb3ATG04XpROYm7I+SbxgbYJMHuCCjNnNy8vuAmlhEyTmgW/TBFKa8KzzhJ4 o/w66bfA27ZNY7BaKGfV2eAX/ReoQgpyyeXhAV+CFx36McQj0tCrXYqvUG7bbeJKag/J NQzQ== MIME-Version: 1.0 X-Received: by 10.112.12.225 with SMTP id b1mr11385294lbc.3.1373309154637; Mon, 08 Jul 2013 11:45:54 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.149.38 with HTTP; Mon, 8 Jul 2013 11:45:54 -0700 (PDT) Date: Mon, 8 Jul 2013 11:45:54 -0700 X-Google-Sender-Auth: klM0fSD6x6IbmLg4GqwwsQyUkG0 Message-ID: Subject: [RFC] Review of mount.conf man page From: Craig Rodrigues To: freebsd-arch@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Marcel Moolenaar 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, 08 Jul 2013 18:45:56 -0000 Hi, In this GRN, Marcel overhauled the root mount logic: ------------------------------------------------------------------------ r214006 | marcel | 2010-10-17 22:01:53 -0700 (Sun, 17 Oct 2010) | 20 lines Re-implement the root mount logic using a recursive approach, whereby each root file system (starting with devfs and a synthesized configuration) can contain directives for mounting another file system as root. ------------------------------------------------------------------------ This stuff is very, very useful, and I have experimented with things like mounting a root file system on a geom_uzip image of a UFS file system and it works great. I looked at these threads to look for some examples: http://lists.freebsd.org/pipermail/freebsd-arch/2010-August/010521.html http://lists.freebsd.org/pipermail/freebsd-arch/2010-August/010547.html and also read the source code of src/sys/kern/vfs_mountroot.c. I would like to contribute a man page for the mount.conf file. My diff is here: http://people.freebsd.org/~rodrigc/mount-conf/mount.conf.diff.txt I also have the man page rendered in ASCII, for easier reading: http://people.freebsd.org/~rodrigc/mount-conf/mount.conf.8.txt Please review and provide feedback. I'd like to get this committed for 9.2 if possible. Thanks to Marcel for writing this code....it's really cool! -- Craig From owner-freebsd-arch@FreeBSD.ORG Mon Jul 8 21:33:31 2013 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BB7C5DC7 for ; Mon, 8 Jul 2013 21:33:31 +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 5727F1A95 for ; Mon, 8 Jul 2013 21:33:30 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id 5E22BA0E; Mon, 8 Jul 2013 23:28:39 +0200 (CEST) Date: Mon, 8 Jul 2013 23:33:52 +0200 From: Pawel Jakub Dawidek To: Jordan Hubbard Subject: Re: General purpose library for name/value pairs. Message-ID: <20130708213351.GB1405@garage.freebsd.pl> References: <20130704215329.GG1402@garage.freebsd.pl> <4818.1373008073@critter.freebsd.dk> <20130705195255.GB25842@garage.freebsd.pl> <60317.1373055040@critter.freebsd.dk> <20130708150308.GE1383@garage.freebsd.pl> <717D098F-D07E-45B0-B9F0-8D8BCEF06923@mail.turbofuzz.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="K8nIJk4ghYZn606h" Content-Disposition: inline In-Reply-To: <717D098F-D07E-45B0-B9F0-8D8BCEF06923@mail.turbofuzz.com> X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 21:33:31 -0000 --K8nIJk4ghYZn606h Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Nice to see you back, Jordan:) On Mon, Jul 08, 2013 at 10:57:17AM -0700, Jordan Hubbard wrote: >=20 > On Jul 8, 2013, at 8:03 AM, Pawel Jakub Dawidek wrote: >=20 > > How about instead of supporting int8, uint8, int16, uint16, int32, > > uint32, int64 and uint64 I'd just support 'number' type, which would be > > uint64_t. This shouldn't break transporting signed values and because I > > don't support basic types like int, long, etc. casting or conversion has > > to be done anyway. This would reduce number of supported types to: >=20 > That's a good idea. Since you're re-inventing Apple's XML property list = API (but without serialization and quite a few other things), keeping the n= umber of supported types down is much better than the converse - exposing t= he details of 16/32/64 bit numbers and their signedness will hang you over = the long term, and you can always provide explicit conversion functions to/= =66rom Number for those who actually care. >=20 > String, Number, Boolean, Data, Date, Array and Dictionary are all plists = support, and Apple developers have gotten along pretty well for many years = with that set (not supporting Dictionaries, btw, is a pretty fundamental lo= ss IMHO - it means you have to always iterate through lists to find your st= uff, which is meh!). I do support nested nvlists. Doesn't that fill the gap? > When Apple extended the Plist metaphor for IPC (to create XPC), they also= added out-of-band types like file and shared memory descriptors. You have= file descriptors, but not shared memory. The latter is kind of important = if you want to do larger IPCs with this mechanism someday and want to suppo= rt "big payloads" transparently without passing the burden of the data mana= gement to the application programmer. FYI, FreeBSD can pass shared memory as file descriptors, see SHM_ANON in shm_open(2). > Before you also come back with "but but this is a kernel API! For just o= ne purpose!" let me just say that it's absolutely achievable to have ONE AP= I for talking userland<->kernel and userland<->userland with the same types= and the transport mechanism(s) largely abstracted away. You don't need tw= o - it's already been done with one, just look next door. :) >=20 > If you add file serialization of this format to your picture (and add the= dictionary type) , bingo, now you have a preferences API that FreeBSD has = lacked from day one ("just roll your own format and stick the file in /etc"= being the canonical response to that need). Interesting. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://mobter.com --K8nIJk4ghYZn606h Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iEYEARECAAYFAlHbMD8ACgkQForvXbEpPzRtjwCgx/zgfLEPl6gfbeRWKCsaxUOJ ILAAnjmBzZEpsfHpeq01R6H9t48HOmNi =2Q/y -----END PGP SIGNATURE----- --K8nIJk4ghYZn606h-- From owner-freebsd-arch@FreeBSD.ORG Mon Jul 8 21:55:52 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B63B71E4; Mon, 8 Jul 2013 21:55:52 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) by mx1.freebsd.org (Postfix) with ESMTP id 386941B34; Mon, 8 Jul 2013 21:55:51 +0000 (UTC) X-AuditID: 1209190e-b7f988e0000009a7-9d-51db35663815 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id FD.9D.02471.6653BD15; Mon, 8 Jul 2013 17:55:50 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id r68Ltoq7025654; Mon, 8 Jul 2013 17:55:50 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id r68Ltleo022338 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 8 Jul 2013 17:55:49 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id r68Ltl6e000770; Mon, 8 Jul 2013 17:55:47 -0400 (EDT) Date: Mon, 8 Jul 2013 17:55:47 -0400 (EDT) From: Benjamin Kaduk To: Craig Rodrigues Subject: Re: [RFC] Review of mount.conf man page In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDIsWRmVeSWpSXmKPExsUixCmqrJtmejvQYMEXE4vZ06cxWXy8OoPd Ym9vD5sDs8eMT/NZAhijuGxSUnMyy1KL9O0SuDL2nJnKVHCYu2Ld9L/MDYzbObsYOTkkBEwk mi90s0DYYhIX7q1n62Lk4hAS2McosXr7cShnA6PEihW9TBDOQSaJhsU9jCAtQgL1EpOObmcG sVkEtCQ+P2tjBbHZBFQkZr7ZyAZiiwhoSnTeXscEYjMLOEucercJbJ2wgIHE202nwOZwCgRK /Hm1F6yXV8BR4sSeH0AzOYDmB0gcmuQMEhYV0JFYvX8KC0SJoMTJmU9YIEZaSpz7c51tAqPg LCSpWUhSCxiZVjHKpuRW6eYmZuYUpybrFicn5uWlFuka6+VmluilppRuYgQHqiTfDsavB5UO MQpwMCrx8M64eCtQiDWxrLgy9xCjJAeTkiivh97tQCG+pPyUyozE4oz4otKc1OJDjBIczEoi vC9UgXK8KYmVValF+TApaQ4WJXHeZ0/PBgoJpCeWpGanphakFsFkZTg4lCR4S02AGgWLUtNT K9Iyc0oQ0kwcnCDDeYCGzwSp4S0uSMwtzkyHyJ9iVJQS511oBJQQAElklObB9cISyStGcaBX hHkNQKp4gEkIrvsV0GAmoMENabdABpckIqSkGhjLZsk0nJ2v8jbTxEHXdANft9Q6i4gJfHPr n309UVh6RfNyyG8Z8V1d003K1L6uedFR+fuOzt3rU4wfqy9+ICxxO9Tq7tUJvFPbLkzgWrNW 6KxLRE3Ghf8vb1h+zaiK41PhWvondMfNUIFWxSPac+8wr09OLM5xM3S7/nd6nPmOkCymvxEl /0KVWIozEg21mIuKEwG/Khq8/wIAAA== Cc: Marcel Moolenaar , 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, 08 Jul 2013 21:55:52 -0000 On Mon, 8 Jul 2013, Craig Rodrigues wrote: > Hi, > > In this GRN, Marcel overhauled the root mount logic: > > ------------------------------------------------------------------------ > r214006 | marcel | 2010-10-17 22:01:53 -0700 (Sun, 17 Oct 2010) | 20 lines > > Re-implement the root mount logic using a recursive approach, whereby each > root file system (starting with devfs and a synthesized configuration) can > contain directives for mounting another file system as root. > ------------------------------------------------------------------------ > > My diff is here: > > http://people.freebsd.org/~rodrigc/mount-conf/mount.conf.diff.txt > > I also have the man page rendered in ASCII, for easier reading: > > http://people.freebsd.org/~rodrigc/mount-conf/mount.conf.8.txt A few notes: our style for man pages (mdoc) is to start a new line for new sentences. I am not sure that the .Cm macro is appropriate to describe .onfail and friends; I guess that devd.conf.5 is using .Ic which might be better. The default font for .Em is supposedly italic, so it may not be best for the mountroot prompt, either. I'm not sure why there are square brackets around the 'N' argument to .timeout; does the default behavior of 3 seconds apply to a .timeout without 'N', or the absence of a .timeout? Can you double-check whether .Pp is needed after .Ed? Thanks for writing this, it's always good to have these things documented. -Ben From owner-freebsd-arch@FreeBSD.ORG Mon Jul 8 22:09:42 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 9A30656E; Mon, 8 Jul 2013 22:09:42 +0000 (UTC) (envelope-from jordan.hubbard@gmail.com) Received: from mail-pd0-x234.google.com (mail-pd0-x234.google.com [IPv6:2607:f8b0:400e:c02::234]) by mx1.freebsd.org (Postfix) with ESMTP id 6FC821BF5; Mon, 8 Jul 2013 22:09:42 +0000 (UTC) Received: by mail-pd0-f180.google.com with SMTP id 10so4505756pdi.11 for ; Mon, 08 Jul 2013 15:09:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=nBmSzNzhXQtmeuXpsudmz3KcilAhAjoQ7F2fYzqiFns=; b=iyNcErrJzn3Wj9ckaAwUw8+8iSTGjNwCCjLXYRyBOWEznBAdwQISO4+fjySWDWyCgQ qqSuwhl6u4w9R6UWrRR3jpSQa63PScbPFlQAV7Qq2esJOObd61suKlq5c/lzSeIRhlLs G3JxxpWqaJDLD7HHZcsIjk0K0iHeMtrY5blws8/s0goDunUcAc4tNCt0odqGW+gixFWp FVMLOwJr4lkX+iMRny9EDrnVVcOnKvVwGXWF9lIU88l0xR1+Wtdy9WL+dn36dz0gHmxy BnIrxD/k6fbxz8AbrXT4RH0njrR+MT7uls0LkK3qRjk02Z045nghl8OFV45y+eIZXEia LhzA== X-Received: by 10.66.119.74 with SMTP id ks10mr25081222pab.179.1373321382296; Mon, 08 Jul 2013 15:09:42 -0700 (PDT) Received: from [10.20.30.70] (75-101-82-48.static.sonic.net. [75.101.82.48]) by mx.google.com with ESMTPSA id v20sm26219304paj.4.2013.07.08.15.09.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 08 Jul 2013 15:09:41 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: General purpose library for name/value pairs. From: "Jordan K. Hubbard" In-Reply-To: <20130708213351.GB1405@garage.freebsd.pl> Date: Mon, 8 Jul 2013 15:09:40 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130704215329.GG1402@garage.freebsd.pl> <4818.1373008073@critter.freebsd.dk> <20130705195255.GB25842@garage.freebsd.pl> <60317.1373055040@critter.freebsd.dk> <20130708150308.GE1383@garage.freebsd.pl> <717D098F-D07E-45B0-B9F0-8D8BCEF06923@mail.turbofuzz.com> <20130708213351.GB1405@garage.freebsd.pl> To: Pawel Jakub Dawidek X-Mailer: Apple Mail (2.1510) Cc: arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 22:09:42 -0000 On Jul 8, 2013, at 2:33 PM, Pawel Jakub Dawidek wrote: > Nice to see you back, Jordan:) Thanks! Now that I'm CTO of iXSystems (and no longer behind Apple's = communications firewall), you can expect to see me around more often! = Not sure if that's a bug or a feature as far as this list is concerned, = but I'll do my best to make it a positive. :) >> String, Number, Boolean, Data, Date, Array and Dictionary are all = plists support, and Apple developers have gotten along pretty well for = many years with that set (not supporting Dictionaries, btw, is a pretty = fundamental loss IMHO - it means you have to always iterate through = lists to find your stuff, which is meh!). >=20 > I do support nested nvlists. Doesn't that fill the gap? Not really, no. In fact, once you support dictionaries, you'll find = that most people prefer them to lists since data can now be passed in = order-independent fashion and evolved over time without breaking older = code. Arrays/lists are far less general purpose and used much less = often (when I checked through a bunch of preference plists on one of my = OS X boxes, I found arrays of types to be the most common). = Nested dictionaries are even far more common in general practice. > FYI, FreeBSD can pass shared memory as file descriptors, see SHM_ANON = in > shm_open(2). OS X supports this as well. The reason we make it an explicit type is = for two reasons. One is lifecycle management - you can't just close a = fd representing a shared memory segment and have all the right things = happen on last close (the segment itself won't be GC'd). The second = reason is that both ends want a fd in one case and an address in the = other and it would be weird to mix and match metaphors just because the = transport wanted to canonicalize everything into fds. - Jordan From owner-freebsd-arch@FreeBSD.ORG Tue Jul 9 08:07:53 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 212C7CB2 for ; Tue, 9 Jul 2013 08:07:53 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from nibbler.fubar.geek.nz (nibbler.fubar.geek.nz [199.48.134.198]) by mx1.freebsd.org (Postfix) with ESMTP id 087651F08 for ; Tue, 9 Jul 2013 08:07:52 +0000 (UTC) Received: from bender.Home (97e5f83b.skybroadband.com [151.229.248.59]) by nibbler.fubar.geek.nz (Postfix) with ESMTPSA id 888EB5E1EF for ; Tue, 9 Jul 2013 08:07:51 +0000 (UTC) Date: Tue, 9 Jul 2013 09:07:44 +0100 From: Andrew Turner To: freebsd-arch@freebsd.org Subject: Adding a MACHINE_ARCH note Message-ID: <20130709090744.0e497e7e@bender.Home> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="MP_/cV0SucBe+552YM4Rrf/l/zD" 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, 09 Jul 2013 08:07:53 -0000 --MP_/cV0SucBe+552YM4Rrf/l/zD Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline I have been looking into an issue where it would be useful to know the value of MACHINE_ARCH a binary was built with, for example on ARM it could be arm or armv6 (or the big endian variants). The reason for this is to teach pkg which arch the package is built for as there are a few differences between arm and armv6 that mean an executable built for one may not run on the other. The attached patch stores the value of MACHINE_ARCH in a note so it can be read later to get this value. Does anyone have any objections to this patch, e.g. there is a better way of doing this? Andrew --MP_/cV0SucBe+552YM4Rrf/l/zD Content-Type: text/x-patch Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=machine_arch_note.diff Index: lib/csu/common/crtbrand.c =================================================================== --- lib/csu/common/crtbrand.c (revision 252514) +++ lib/csu/common/crtbrand.c (working copy) @@ -64,3 +64,17 @@ .name = NOTE_FREEBSD_VENDOR, .desc = __FreeBSD_version }; + +static const struct { + int32_t namesz; + int32_t descsz; + int32_t type; + char name[sizeof(NOTE_FREEBSD_VENDOR)]; + char desc[sizeof(MACHINE_ARCH)]; +} archtag __attribute__ ((section (NOTE_SECTION), aligned(4))) __used = { + .namesz = sizeof(NOTE_FREEBSD_VENDOR), + .descsz = sizeof(MACHINE_ARCH), + .type = ARCH_NOTETYPE, + .name = NOTE_FREEBSD_VENDOR, + .desc = MACHINE_ARCH +}; Index: lib/csu/common/notes.h =================================================================== --- lib/csu/common/notes.h (revision 252514) +++ lib/csu/common/notes.h (working copy) @@ -34,5 +34,6 @@ #define ABI_NOTETYPE 1 #define CRT_NOINIT_NOTETYPE 2 +#define ARCH_NOTETYPE 3 #endif --MP_/cV0SucBe+552YM4Rrf/l/zD-- From owner-freebsd-arch@FreeBSD.ORG Tue Jul 9 10:42:52 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 988B58C2 for ; Tue, 9 Jul 2013 10:42:52 +0000 (UTC) (envelope-from rmh.aybabtu@gmail.com) Received: from mail-qe0-x232.google.com (mail-qe0-x232.google.com [IPv6:2607:f8b0:400d:c02::232]) by mx1.freebsd.org (Postfix) with ESMTP id 63AA51839 for ; Tue, 9 Jul 2013 10:42:52 +0000 (UTC) Received: by mail-qe0-f50.google.com with SMTP id f6so2936794qej.9 for ; Tue, 09 Jul 2013 03:42:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=q08uKxVkwccBDgQUJxi/Ox5e54GiK46xyyku5iT3zFU=; b=z1CWNMiUo+RO+Nr9o4QSXX+6/F/Lk9dn/VUZTVdBfjNdHL2wk5guOb4PlTYgz9Xt7l fvnfvH1aJzdJBNQARoLAUR1L5Jt2Hl24RXGXQ7Ku0Ye7lCqyBZi9JQsLwL01egfGgJtC rNyEB1F1qfXh/KO+jn836NXkQkjPr7dxHgBt+7tRAZW3sKGSrFmh0LP29MHNKvdmwzig c8VcJIVASMt6xR4aBJaRYXj0ROwimzFzaEMrCmcRqsi3CFR+oN6ymX0FcnriT03zPbwf aXy+J5ekDXeZy0K63OJGkR3idT+ZD048KWeIe7yqyDFmcf87/QATt0JZWJtEqRe/FImv 3z1Q== MIME-Version: 1.0 X-Received: by 10.49.83.73 with SMTP id o9mr19636834qey.71.1373366571933; Tue, 09 Jul 2013 03:42:51 -0700 (PDT) Sender: rmh.aybabtu@gmail.com Received: by 10.49.26.193 with HTTP; Tue, 9 Jul 2013 03:42:51 -0700 (PDT) Date: Tue, 9 Jul 2013 12:42:51 +0200 X-Google-Sender-Auth: ktW80ktZVoMtPJLWwFehQQ1Zek0 Message-ID: Subject: libutil in Debian From: Robert Millan To: freebsd-arch@freebsd.org Content-Type: text/plain; charset=UTF-8 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, 09 Jul 2013 10:42:52 -0000 Hi, The FreeBSD libutil library has a number of facilities which are not specific to FreeBSD and could be useful on other systems. In Debian we have a bunch of FreeBSD libraries already (see [1]). When ever possible (e.g. libsbuf) the library is provided to all Debian platforms, not just those using the kernel of FreeBSD. As of now we do not have libutil though, because since Glibc already provides a library with this name, we would have to rename it. Renaming libutil ourselves is a big nuissance, because we'd be diverging from FreeBSD, and our porting work would also have to differ from FreeBSD's. Things are much easier for us if we can use the same name FreeBSD does. Would it be possible for this library to be renamed in FreeBSD? Then we could quickly follow suit and package it. Any name you're comfortable with could do. My only concern is about avoiding namespace collisions. Thanks for considering [1] http://packages.debian.org/source/sid/freebsd-libs -- Robert Millan From owner-freebsd-arch@FreeBSD.ORG Tue Jul 9 11:06: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 18B92F9F for ; Tue, 9 Jul 2013 11:06:36 +0000 (UTC) (envelope-from benno@FreeBSD.org) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id C934C192A for ; Tue, 9 Jul 2013 11:06:35 +0000 (UTC) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id E381120EDD; Tue, 9 Jul 2013 07:06:34 -0400 (EDT) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute1.internal (MEProxy); Tue, 09 Jul 2013 07:06:34 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id :references:to; s=smtpout; bh=UtMUvExu8X87Im3xZjVLtC8ZLBI=; b=Ss sRqWaCmsFOfaTO4+BzCeKksVU5fYveZN9e0j2WbJitwlgS2WhZX8ma3diddHIKvD grObqUBN7zgqYRv3+1KvE/S5pW5tKN+xk+S+Rg0b+YhEUhXDqz05uJ+X0z7CNZjc ut/ZFpjRLSvO9qAJ3XsQHFav4NWuWdmMp5YgKiv0A= X-Sasl-enc: e7I9qYMu0sfOxeX+nMmtUAEV5OaOHL7KCHtYqZRbJ7Ql 1373367994 Received: from mittlerweile.fritz.box (unknown [118.209.106.43]) by mail.messagingengine.com (Postfix) with ESMTPA id CF665680279; Tue, 9 Jul 2013 07:06:33 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: Reworking vmmeter From: Benno Rice In-Reply-To: <20130707052553.GC91021@kib.kiev.ua> Date: Tue, 9 Jul 2013 21:06:33 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <5A9BF932-4B00-4CE6-AC11-1673CD57A8CF@FreeBSD.org> References: <20130707052553.GC91021@kib.kiev.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.1508) 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: Tue, 09 Jul 2013 11:06:36 -0000 Apologies for the delay, I've been at a conference. Replies inline. On 07/07/2013, at 3:25 PM, Konstantin Belousov = wrote: > On Sun, Jul 07, 2013 at 09:53:37AM +1000, Benno Rice wrote: >> So I've put together this patch: >>=20 >> http://people.freebsd.org/~benno/vmmeter.diff >>=20 >> This patch does a few things: >>=20 >> - Renames the singleton "cnt" to "vmmeter". >> - Replaces all the per-cpu counters with counter_u64_t. >> - Removes the vmmeter instance from struct pcpu, due to the above = mentioned change. >> - Adds includes for vmmeter.h to a few files that were only getting = it via pollution in pcpu.h >> - Removes some entries from assym that weren't being used. >>=20 >> This has been tested on amd64 and nothing else right now, I'm more = posting this to get general comments on whether people think this is a = good idea. My motivation for this was twofold, firstly to rename cnt and = secondly to move the counters to the common counter framework. More = testing will be done prior to commit. >>=20 >=20 > Why did you removed the CTASSERT from sys/pcpu.h ? Because it was no longer a multiple of PAGE_SIZE but significantly less. = I'm open to how to approach this but it seemed that since we were now = less than PAGE_SIZE it was less important. > Your edits for the inlines in the sys/vmmeter.h are notoriously > violating style. I converted them from four-space to one-tab indents, I thought that made = them more compliant rather than less. > You probably could add some macro like COUNTER_U64_INITIALIZED(), = which > would check for the counter containing non-NULL pointer. At least = this > would allow to remove vmmeter_use_early_counters. Still the hack of > early_*_faults cannot be avoided this way. Or, since BSP is = guaranteed > to have id 0, you could temporary put a pointer to the early_*_faults > into the counter_u64_t, which is to be overwritten after the real = counter > is initialized. Then the if()s in the vm_fault() can be removed. I went through a few iterations of how to approach these. Your approach = might be slightly neater but pretty much everything feels mildly = hackish. If there was some way we could allow counters to be allocated = in an "early" mode before the pcpu stuff was available and then = "upgraded" later that could be neater but I'm not sure the complexity is = worth it. > Note that the parts of counters(9) KPI used in your patch has known > issue on some 32 bit arches, namely powerpc32, mips32 and arm. The = fetch > could loose the carry bit in a cell, transiently. This is a bug in the > platform implementation, and not the inherent counters(9) limitation. > Fixing requires some asm magic (basically, the counter cells updates = and > fetches must be 64bit atomics). This is done on i386 already, and > the problem does not exist on 64bit arches. Ok, are you looking at fixing that for these architectures or is this = something that's waiting on a solution? From owner-freebsd-arch@FreeBSD.ORG Tue Jul 9 11:35:55 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 873F4A61; Tue, 9 Jul 2013 11:35:55 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) by mx1.freebsd.org (Postfix) with ESMTP id 74F051A2C; Tue, 9 Jul 2013 11:35:54 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.7/8.14.7) with ESMTP id r69BZrP5094288; Tue, 9 Jul 2013 15:35:53 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.7/8.14.7/Submit) id r69BZrkw094287; Tue, 9 Jul 2013 15:35:53 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 9 Jul 2013 15:35:53 +0400 From: Gleb Smirnoff To: Robert Millan Subject: Re: libutil in Debian Message-ID: <20130709113553.GP67810@FreeBSD.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r 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: Tue, 09 Jul 2013 11:35:55 -0000 Robert, On Tue, Jul 09, 2013 at 12:42:51PM +0200, Robert Millan wrote: R> The FreeBSD libutil library has a number of facilities which are not R> specific to FreeBSD and could be useful on other systems. R> R> In Debian we have a bunch of FreeBSD libraries already (see [1]). When R> ever possible (e.g. libsbuf) the library is provided to all Debian R> platforms, not just those using the kernel of FreeBSD. R> R> As of now we do not have libutil though, because since Glibc already R> provides a library with this name, we would have to rename it. R> Renaming libutil ourselves is a big nuissance, because we'd be R> diverging from FreeBSD, and our porting work would also have to differ R> from FreeBSD's. Things are much easier for us if we can use the same R> name FreeBSD does. R> R> Would it be possible for this library to be renamed in FreeBSD? Then R> we could quickly follow suit and package it. Any name you're R> comfortable with could do. My only concern is about avoiding namespace R> collisions. R> R> Thanks for considering R> R> [1] http://packages.debian.org/source/sid/freebsd-libs With all respect to GNU and Debian the libutil in BSD appeared in 1988, and the fact that GNU has taken that name in 1996 isn't reason for BSD to change name. Also, FreeBSD is just one of the BSD descendants, and all of them share the libutil. P.S. This is my personal opinion, not projects position. -- Totus tuus, Glebius. From owner-freebsd-arch@FreeBSD.ORG Tue Jul 9 12:54:28 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 43E23B47; Tue, 9 Jul 2013 12:54:28 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id AB3EC1E23; Tue, 9 Jul 2013 12:54:27 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r69CsFVH027132; Tue, 9 Jul 2013 15:54:15 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r69CsFVH027132 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r69CsFwa027131; Tue, 9 Jul 2013 15:54:15 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 9 Jul 2013 15:54:15 +0300 From: Konstantin Belousov To: Benno Rice Subject: Re: Reworking vmmeter Message-ID: <20130709125415.GK91021@kib.kiev.ua> References: <20130707052553.GC91021@kib.kiev.ua> <5A9BF932-4B00-4CE6-AC11-1673CD57A8CF@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OLEmQOz5exAyrbxI" Content-Disposition: inline In-Reply-To: <5A9BF932-4B00-4CE6-AC11-1673CD57A8CF@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: 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, 09 Jul 2013 12:54:28 -0000 --OLEmQOz5exAyrbxI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 09, 2013 at 09:06:33PM +1000, Benno Rice wrote: > Apologies for the delay, I've been at a conference. Replies inline. >=20 > On 07/07/2013, at 3:25 PM, Konstantin Belousov wrot= e: >=20 > > On Sun, Jul 07, 2013 at 09:53:37AM +1000, Benno Rice wrote: > >> So I've put together this patch: > >>=20 > >> http://people.freebsd.org/~benno/vmmeter.diff > >>=20 > >> This patch does a few things: > >>=20 > >> - Renames the singleton "cnt" to "vmmeter". > >> - Replaces all the per-cpu counters with counter_u64_t. > >> - Removes the vmmeter instance from struct pcpu, due to the above ment= ioned change. > >> - Adds includes for vmmeter.h to a few files that were only getting it= via pollution in pcpu.h > >> - Removes some entries from assym that weren't being used. > >>=20 > >> This has been tested on amd64 and nothing else right now, I'm more pos= ting this to get general comments on whether people think this is a good id= ea. My motivation for this was twofold, firstly to rename cnt and secondly = to move the counters to the common counter framework. More testing will be = done prior to commit. > >>=20 > >=20 > > Why did you removed the CTASSERT from sys/pcpu.h ? >=20 > Because it was no longer a multiple of PAGE_SIZE but significantly less. = I'm open to how to approach this but it seemed that since we were now less = than PAGE_SIZE it was less important. >=20 The assert did not verified that size of struct pcpu is multiple of page size. Please re-read the comment above. You must properly pad struct pcpu, using md fields. > > Your edits for the inlines in the sys/vmmeter.h are notoriously > > violating style. >=20 > I converted them from four-space to one-tab indents, I thought that made = them more compliant rather than less. >=20 Style recommends to fill the line instead of placing single '(' on it. The continuation lines should have additional 4-space indent. > > You probably could add some macro like COUNTER_U64_INITIALIZED(), which > > would check for the counter containing non-NULL pointer. At least this > > would allow to remove vmmeter_use_early_counters. Still the hack of > > early_*_faults cannot be avoided this way. Or, since BSP is guaranteed > > to have id 0, you could temporary put a pointer to the early_*_faults > > into the counter_u64_t, which is to be overwritten after the real count= er > > is initialized. Then the if()s in the vm_fault() can be removed. >=20 > I went through a few iterations of how to approach these. Your approach m= ight be slightly neater but pretty much everything feels mildly hackish. If= there was some way we could allow counters to be allocated in an "early" m= ode before the pcpu stuff was available and then "upgraded" later that coul= d be neater but I'm not sure the complexity is worth it. >=20 It still feels hackish, but it avoids adding the if () conditional to the (hot) vm_fault() path. > > Note that the parts of counters(9) KPI used in your patch has known > > issue on some 32 bit arches, namely powerpc32, mips32 and arm. The fetch > > could loose the carry bit in a cell, transiently. This is a bug in the > > platform implementation, and not the inherent counters(9) limitation. > > Fixing requires some asm magic (basically, the counter cells updates and > > fetches must be 64bit atomics). This is done on i386 already, and > > the problem does not exist on 64bit arches. >=20 > Ok, are you looking at fixing that for these architectures or is this som= ething that's waiting on a solution? I can learn and write required assembler, but I cannot test due to lack of hardware. My calls for test for previous work usually end with silence, so I decided to not care about other architectures more than corresponding maintainers. --OLEmQOz5exAyrbxI Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIbBAEBAgAGBQJR3Af2AAoJEJDCuSvBvK1BzWwP+PaYbaFO1BGi4USBztnvnXCS /x15swljrx92MjO97yV3tQNj63z28Dz/bGDx/Pmzl63KeU+Q3PauRnt/6YBxSQUp np7dNSRyXIlkdKxcSe8Pm1USJgJ5em+JXJYbgICPcQFPo61kNzLGnX06faUeRdo9 Rz86X42FQENyEL/w9wHxgl9m/PAfAnbUokhesCXtUYjlIv6QrwXh32quNjiHq0v/ GNvVE6yBP1+8GMl+JdeKscp5iLhY2Ah7mswtbRjbF2P1/COva099jNirJS2k9NKB F3Au10xM1LF0h6mX2naUzbfmGXZ8C5EGigZI35ft6+6FBytawDiiStn0s2zonVhb cK26oUIeoV3nh3o51MBLPh7vw98kK7ADCPkF4nuJ4R78YH0WdAncbfj39oMEbROl AYaOr967kURyU4N1OiwhR4EltoOAy59jCSghlo1UnsOFnTXvgXuDTVxVwhlXBFTx oEvarGHvWl76Ro0atnAH9fy1KgsSJYghRskrspNw+gW+U2PTworGAdRk6jd6s6bL r80+UCRIRvMhwECo9LJCIqwmJp7rqIAQe+TISZq/wogDsL7TChA/RED9w9McpnxP PUpvzXogrvA1mdG3DG4Tn04HR52AnmR07a/j6GlxNTwvKvPlxcNL47NE/n+dej0P m6mpwTeKJhK1sMcnuXE= =YGLu -----END PGP SIGNATURE----- --OLEmQOz5exAyrbxI-- From owner-freebsd-arch@FreeBSD.ORG Tue Jul 9 14:19: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 148E8A3B for ; Tue, 9 Jul 2013 14:19:51 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-f179.google.com (mail-ie0-f179.google.com [209.85.223.179]) by mx1.freebsd.org (Postfix) with ESMTP id DC50E1285 for ; Tue, 9 Jul 2013 14:19:50 +0000 (UTC) Received: by mail-ie0-f179.google.com with SMTP id c10so13132058ieb.10 for ; Tue, 09 Jul 2013 07:19:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=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=FQYksdRycXuZ2tFBrvntgCgQxP0JDgiDmEZbXoED+xQ=; b=UcMIylhXO0qR/WNNY4QV5byl2uGUekXWfq3rzpB/JF3D3SkRmkbzPpx3wG8dt348+t u9oeNPGDnIaj+75rLyiGNdvrN7G6d6PznfxoUy47HcNS2ZkgCzKwyerKV4uoDiwH4Spj pJF0YSk0k+FfA9ecrDcQlSeblEu8M3lSBOkeZXok03JKZJzP59Sii+25cvGshLfJtEzP MFoFim89hJHRZXwhLaVb+8pHHBspBin9YlDLOrRh5kehUG71K8WFOAfmjHQtwXNxwcO0 xO0gNNU3R/Ru/hHcqn3BgMfwOfonrcnPKxFIEUooUFgI4tQLS7EXY6BnyVFJT6Me6qhE nbfw== X-Received: by 10.50.80.9 with SMTP id n9mr10281634igx.42.1373379590307; Tue, 09 Jul 2013 07:19:50 -0700 (PDT) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id ht10sm10450349igb.2.2013.07.09.07.19.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Jul 2013 07:19:48 -0700 (PDT) Sender: Warner Losh Subject: Re: Adding a MACHINE_ARCH note Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20130709090744.0e497e7e@bender.Home> Date: Tue, 9 Jul 2013 08:19:46 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <32F979BD-FB5C-4111-9586-4C5E7C6DFA71@bsdimp.com> References: <20130709090744.0e497e7e@bender.Home> To: Andrew Turner X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQnvE5X5OJP0rqCBQdjaFiE6Dno5ZqMXMxYRaqWvM1B/9J/vT9qZFgbPdBANDHm0DcJswTM3 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: Tue, 09 Jul 2013 14:19:51 -0000 On Jul 9, 2013, at 2:07 AM, Andrew Turner wrote: > I have been looking into an issue where it would be useful to know the > value of MACHINE_ARCH a binary was built with, for example on ARM it > could be arm or armv6 (or the big endian variants). >=20 > The reason for this is to teach pkg which arch the package is built = for > as there are a few differences between arm and armv6 that mean > an executable built for one may not run on the other. >=20 > The attached patch stores the value of MACHINE_ARCH in a note so it = can > be read later to get this value. Does anyone have any objections to > this patch, e.g. there is a better way of doing this? I thought that the ELF headers gave us all the data we needed to know = how things were built... Warner From owner-freebsd-arch@FreeBSD.ORG Tue Jul 9 15:05: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 D2403A80; Tue, 9 Jul 2013 15:05:00 +0000 (UTC) (envelope-from rmh.aybabtu@gmail.com) Received: from mail-qa0-x236.google.com (mail-qa0-x236.google.com [IPv6:2607:f8b0:400d:c00::236]) by mx1.freebsd.org (Postfix) with ESMTP id 89CF31653; Tue, 9 Jul 2013 15:05:00 +0000 (UTC) Received: by mail-qa0-f54.google.com with SMTP id n20so2949802qaj.6 for ; Tue, 09 Jul 2013 08:05:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=CY1PyDGz+I92IjX4uWi/1ARwGh2iLtZj/eisHL/ZmjA=; b=o2xdvbyck38/Je160ptG/0HLLb1uIgKPIlZBk7bvVUlDPXrjOYiAL1b8cffHjBG8b9 liYD9KQxGltP6GOoDMlEn8ZMQGjuA7ITR7Lu61PWE5lxYUR2ORQv6+SBtsLJAHq6iyla 3uEmp1aggiGcyxsu+/x/0+dizpNpmphlQVjLFxn0VO3HlxtFgLMqxWJD8ePbwDbI6W/J s5c4KsuwVjbsX+dlfgLdrvvevKs2n3vAmmEqKjW/HA1+1CLL6rXp/dem1BYXx+HojTqH 4ZYv2e60Feit9pHAoUlmyFHA221uSGLwRrPi9MaaeqW+v+tLydQvljnYXzsYawqfmyWc QB0Q== MIME-Version: 1.0 X-Received: by 10.224.165.77 with SMTP id h13mr14241421qay.58.1373382300126; Tue, 09 Jul 2013 08:05:00 -0700 (PDT) Sender: rmh.aybabtu@gmail.com Received: by 10.49.26.193 with HTTP; Tue, 9 Jul 2013 08:05:00 -0700 (PDT) In-Reply-To: <20130709113553.GP67810@FreeBSD.org> References: <20130709113553.GP67810@FreeBSD.org> Date: Tue, 9 Jul 2013 17:05:00 +0200 X-Google-Sender-Auth: F0l9_NgAP7IxumuhZkVTRs52jgQ Message-ID: Subject: Re: libutil in Debian From: Robert Millan To: Gleb Smirnoff Content-Type: text/plain; charset=UTF-8 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: Tue, 09 Jul 2013 15:05:00 -0000 Hi Gleb, 2013/7/9 Gleb Smirnoff : > With all respect to GNU and Debian the libutil in BSD appeared in 1988, > and the fact that GNU has taken that name in 1996 isn't reason for BSD > to change name. Thanks for pointing this out. Please note that my request is only based on practical grounds. It shouldn't be interpreted as implying endorsement on Glibc's use of libutil name. Historically, Glibc maintainer has been very difficult to deal with. This has affected non-Linux ports of Glibc as well. In contrast, FreeBSD community may or may not agree with proposals but is at least open to discuss things. This (rather than "fairness") is the reason I try to work things out here and not there. Please take it as a compliment rather than as offence :-) > Also, FreeBSD is just one of the BSD descendants, and all of them share > the libutil. So, I take it that the change I'm proposing could have disruptive effects. I do think there are long-term advantages for FreeBSD and the other BSD descendants in making it easy for their APIs to be deployed elsewhere. I mean, in terms of portability. However I'm clearly biased so I'd rather not insist on this. I leave it for you to judge. Thanks! -- Robert Millan From owner-freebsd-arch@FreeBSD.ORG Tue Jul 9 16:12:28 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 DED5E80C; Tue, 9 Jul 2013 16:12:28 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) by mx1.freebsd.org (Postfix) with ESMTP id B97931AA8; Tue, 9 Jul 2013 16:12:28 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id AF0A3B94A; Tue, 9 Jul 2013 12:12:25 -0400 (EDT) From: John Baldwin To: freebsd-arch@freebsd.org Subject: Re: General purpose library for name/value pairs. Date: Tue, 9 Jul 2013 10:39:26 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <20130704215329.GG1402@garage.freebsd.pl> <20130708213351.GB1405@garage.freebsd.pl> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201307091039.26835.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 09 Jul 2013 12:12:25 -0400 (EDT) Cc: "Jordan K. Hubbard" 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, 09 Jul 2013 16:12:28 -0000 On Monday, July 08, 2013 6:09:40 pm Jordan K. Hubbard wrote: > > FYI, FreeBSD can pass shared memory as file descriptors, see SHM_ANON in > > shm_open(2). > > OS X supports this as well. The reason we make it an explicit type is for two reasons. One is lifecycle management - you can't just close a fd representing a shared memory segment and have all the right things happen on last close (the segment itself won't be GC'd). The second reason is that both ends want a fd in one case and an address in the other and it would be weird to mix and match metaphors just because the transport wanted to canonicalize everything into fds. I'll only speak to the GC point. For anonymous shm's (SHM_ANON), the segment is in fact GC'd on last close as there is no name to hold a reference to it. Note that this is an extension to the POSIX API. These anonymous objects are in fact quite useful for creating arbitrary shms, and we even have an API for mapping them into KVA so that they can be great tools for doing shared memory IPC between userland and kernel. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Tue Jul 9 16:29: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 E802517D; Tue, 9 Jul 2013 16:29:39 +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 D800F1BC5; Tue, 9 Jul 2013 16:29:39 +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 8C0C71A3C30; Tue, 9 Jul 2013 09:29:37 -0700 (PDT) Message-ID: <51DC3A71.5040204@mu.org> Date: Tue, 09 Jul 2013 09:29:37 -0700 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Robert Millan Subject: Re: libutil in Debian References: <20130709113553.GP67810@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Gleb Smirnoff , 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, 09 Jul 2013 16:29:40 -0000 On 7/9/13 8:05 AM, Robert Millan wrote: > Hi Gleb, > > 2013/7/9 Gleb Smirnoff : >> With all respect to GNU and Debian the libutil in BSD appeared in 1988, >> and the fact that GNU has taken that name in 1996 isn't reason for BSD >> to change name. > Thanks for pointing this out. > > Please note that my request is only based on practical grounds. It > shouldn't be interpreted as implying endorsement on Glibc's use of > libutil name. > > Historically, Glibc maintainer has been very difficult to deal with. > This has affected non-Linux ports of Glibc as well. In contrast, > FreeBSD community may or may not agree with proposals but is at least > open to discuss things. This (rather than "fairness") is the reason I > try to work things out here and not there. > > Please take it as a compliment rather than as offence :-) > >> Also, FreeBSD is just one of the BSD descendants, and all of them share >> the libutil. > So, I take it that the change I'm proposing could have disruptive effects. > > I do think there are long-term advantages for FreeBSD and the other > BSD descendants in making it easy for their APIs to be deployed > elsewhere. I mean, in terms of portability. > > However I'm clearly biased so I'd rather not insist on this. I leave > it for you to judge. > Robert, I can't promise anything other than maybe a proof of concept in patch form would work? We already do have some utils we have in our base renamed to avoid conflicts such as lib*bsd*yaml. Maybe there's a way to make this work since our system is tightly integrated. Have you looked at what happens with autoconf/automake? How bad does it look from that PoV? Are there a ton of scripts that pull in libutil? Or is that only a small portion of the base? Do you know how to do ports build on FreeBSD to see what breaks? -- Alfred Perlstein VP Software Engineering, iXsystems From owner-freebsd-arch@FreeBSD.ORG Tue Jul 9 16:59: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 A09A48C9; Tue, 9 Jul 2013 16:59:43 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 4226A1D35; Tue, 9 Jul 2013 16:59:43 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r69GxdkZ077529; Tue, 9 Jul 2013 19:59:39 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r69GxdkZ077529 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r69GxdGW077528; Tue, 9 Jul 2013 19:59:39 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 9 Jul 2013 19:59:39 +0300 From: Konstantin Belousov To: Robert Millan Subject: Re: libutil in Debian Message-ID: <20130709165939.GP91021@kib.kiev.ua> References: <20130709113553.GP67810@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SE5owWcayr8rNfUr" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: Gleb Smirnoff , 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, 09 Jul 2013 16:59:43 -0000 --SE5owWcayr8rNfUr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 09, 2013 at 05:05:00PM +0200, Robert Millan wrote: > Hi Gleb, >=20 > 2013/7/9 Gleb Smirnoff : > > With all respect to GNU and Debian the libutil in BSD appeared in 1988, > > and the fact that GNU has taken that name in 1996 isn't reason for BSD > > to change name. >=20 > Thanks for pointing this out. >=20 > Please note that my request is only based on practical grounds. It > shouldn't be interpreted as implying endorsement on Glibc's use of > libutil name. >=20 > Historically, Glibc maintainer has been very difficult to deal with. > This has affected non-Linux ports of Glibc as well. In contrast, > FreeBSD community may or may not agree with proposals but is at least > open to discuss things. This (rather than "fairness") is the reason I > try to work things out here and not there. >=20 > Please take it as a compliment rather than as offence :-) >=20 > > Also, FreeBSD is just one of the BSD descendants, and all of them share > > the libutil. >=20 > So, I take it that the change I'm proposing could have disruptive effects. >=20 > I do think there are long-term advantages for FreeBSD and the other > BSD descendants in making it easy for their APIs to be deployed > elsewhere. I mean, in terms of portability. >=20 > However I'm clearly biased so I'd rather not insist on this. I leave > it for you to judge. Renaming the libutil would break the ABI of the base system. If you are introducing new interfaces to the other systems, you can use a library name you find suitable. But for the library which is linked with significant number of existing binaries, rename is not an easy option. --SE5owWcayr8rNfUr Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJR3EF6AAoJEJDCuSvBvK1BegQP/jKmvwDByVO8g0Zd9Hz5D86J 9lJ+cIGZRwwXU6N8welSUD5M2YOt5kkeGDBdgXKTrrkgKkxqCyacdRCvfYQpi41H +9gCsKVTVxUrudZxALxe6eEmYnAkgXyrRiXiUTNquQK5V1QHxU2j0YEg2Y247NWM 1fGn1rQa6EEZV++2o3bNf5hJN377elsr6aoU4mw2l+yczxCmdhn0cecUp9kfj4Yc tphL4Ru16x+trVQpuh9/jmjKYo4IlaKHszblggXyGYxdp6pl9I/2WWWEckKnluV5 C+uZ4B3lJZX+Pv1jVVZ9sHRpaKXSh4WGoiJbv/3m2Y3uHXaYgAZuSI8FraCb2fWW sskKaHSTPuHOlQvCgIT+9PE6iACHknJeNikCNunq4LyqBzjy+ytsmR4Pw3Zv24Sb J/7EblMNwb5yl3iu2YYahZirSampUyZGRYZsZ679d8Aaq9E6SkFIyDzej8sms0yJ tI0W3ZE59rxTfREYja4x23zCsjPM11tXmREOCu4NqcpNS9OdHttS59E8HHEuMqqR 3OxQle3sA6RCKbHlbvQ8d+fPaZkAYo0g0oT/O7BpNkGozDp1ieCYt009ICwnF5SG rJEcS3Afz2a+ViEMvVlMuooQLExWqLQmTOY28nCEGzOci0Ny6pSIJCzTyFjVIsrp ZwMr9YJpWDylFoGy89Kl =PkAM -----END PGP SIGNATURE----- --SE5owWcayr8rNfUr-- From owner-freebsd-arch@FreeBSD.ORG Tue Jul 9 17:19: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 D2B162D9 for ; Tue, 9 Jul 2013 17:19:15 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-oa0-f52.google.com (mail-oa0-f52.google.com [209.85.219.52]) by mx1.freebsd.org (Postfix) with ESMTP id 9E1B01E55 for ; Tue, 9 Jul 2013 17:19:15 +0000 (UTC) Received: by mail-oa0-f52.google.com with SMTP id g12so8338701oah.11 for ; Tue, 09 Jul 2013 10:19:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=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=lpG5wUPiQn9SAF5i9f8YCfp5SMgMZuHKYW8iEDQDJJA=; b=Y3kuyM/E+9eBKTfZCv5h3IFU7xPBfp7q+fnEGqy8bNDSQGlVxLXI3O00rHS9R/sFC1 ebwxYJo6LPrGjGieCnlSc0Q9O8GN4GWSiDvIyalNTM0LqUj5rfOOTdbrDqEmp5HkbPI9 eI9h2tARuacFT3x3xWkMk5egpvl5D20ggOqC94xkdu6TzuXvN041H1TPtIASSgfXt6cP kOAkEDW8/mS+B/jay8ehF0rBijpT6QOXvL0aTBv+LEF7/5TVlxVfHxdyqvLe9WxZk/dD yDEjDlnlc21GQuIjHPuiXOtxnIbFNxB02i+SllGpKwCWrlkXVnJqX0CPKQaRhzxFW2P4 ZyPA== X-Received: by 10.182.87.73 with SMTP id v9mr24834377obz.90.1373390005231; Tue, 09 Jul 2013 10:13:25 -0700 (PDT) Received: from monkey-bot.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPSA id o4sm39022323obl.7.2013.07.09.10.13.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Jul 2013 10:13:24 -0700 (PDT) Sender: Warner Losh Subject: Re: libutil in Debian Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20130709165939.GP91021@kib.kiev.ua> Date: Tue, 9 Jul 2013 11:13:23 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <0657575A-BF3A-486F-9582-C01E0FD97E38@bsdimp.com> References: <20130709113553.GP67810@FreeBSD.org> <20130709165939.GP91021@kib.kiev.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQlVWa4gPnxEdEHhRXsoushy4RN7oOThYrDFLssE8WspyC2Yu29ElnZD3Si4xBaLD6A33yX9 Cc: freebsd-arch@freebsd.org, Gleb Smirnoff , Robert Millan 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, 09 Jul 2013 17:19:15 -0000 On Jul 9, 2013, at 10:59 AM, Konstantin Belousov wrote: > On Tue, Jul 09, 2013 at 05:05:00PM +0200, Robert Millan wrote: >> Hi Gleb, >>=20 >> 2013/7/9 Gleb Smirnoff : >>> With all respect to GNU and Debian the libutil in BSD appeared in = 1988, >>> and the fact that GNU has taken that name in 1996 isn't reason for = BSD >>> to change name. >>=20 >> Thanks for pointing this out. >>=20 >> Please note that my request is only based on practical grounds. It >> shouldn't be interpreted as implying endorsement on Glibc's use of >> libutil name. >>=20 >> Historically, Glibc maintainer has been very difficult to deal with. >> This has affected non-Linux ports of Glibc as well. In contrast, >> FreeBSD community may or may not agree with proposals but is at least >> open to discuss things. This (rather than "fairness") is the reason I >> try to work things out here and not there. >>=20 >> Please take it as a compliment rather than as offence :-) >>=20 >>> Also, FreeBSD is just one of the BSD descendants, and all of them = share >>> the libutil. >>=20 >> So, I take it that the change I'm proposing could have disruptive = effects. >>=20 >> I do think there are long-term advantages for FreeBSD and the other >> BSD descendants in making it easy for their APIs to be deployed >> elsewhere. I mean, in terms of portability. >>=20 >> However I'm clearly biased so I'd rather not insist on this. I leave >> it for you to judge. >=20 > Renaming the libutil would break the ABI of the base system. > If you are introducing new interfaces to the other systems, you > can use a library name you find suitable. But for the library > which is linked with significant number of existing binaries, > rename is not an easy option. Can we use libmap.conf to create an alias for the new name on FreeBSD so = that programs that link against libbsdutil, to pick an arbitrary name, = can work and libbsdutil can be packaged for debian? This will allow = things to be portable, while allowing repackaging by Debian. Warner= From owner-freebsd-arch@FreeBSD.ORG Tue Jul 9 17:20:56 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 2994A4EA; Tue, 9 Jul 2013 17:20:56 +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 17D191E73; Tue, 9 Jul 2013 17:20:56 +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 D0FF01A3CF9; Tue, 9 Jul 2013 10:20:55 -0700 (PDT) Message-ID: <51DC4677.20809@mu.org> Date: Tue, 09 Jul 2013 10:20:55 -0700 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Warner Losh Subject: Re: libutil in Debian References: <20130709113553.GP67810@FreeBSD.org> <20130709165939.GP91021@kib.kiev.ua> <0657575A-BF3A-486F-9582-C01E0FD97E38@bsdimp.com> In-Reply-To: <0657575A-BF3A-486F-9582-C01E0FD97E38@bsdimp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Konstantin Belousov , Gleb Smirnoff , Robert Millan , 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, 09 Jul 2013 17:20:56 -0000 On 7/9/13 10:13 AM, Warner Losh wrote: > On Jul 9, 2013, at 10:59 AM, Konstantin Belousov wrote: > >> On Tue, Jul 09, 2013 at 05:05:00PM +0200, Robert Millan wrote: >>> Hi Gleb, >>> >>> 2013/7/9 Gleb Smirnoff : >>>> With all respect to GNU and Debian the libutil in BSD appeared in 1988, >>>> and the fact that GNU has taken that name in 1996 isn't reason for BSD >>>> to change name. >>> Thanks for pointing this out. >>> >>> Please note that my request is only based on practical grounds. It >>> shouldn't be interpreted as implying endorsement on Glibc's use of >>> libutil name. >>> >>> Historically, Glibc maintainer has been very difficult to deal with. >>> This has affected non-Linux ports of Glibc as well. In contrast, >>> FreeBSD community may or may not agree with proposals but is at least >>> open to discuss things. This (rather than "fairness") is the reason I >>> try to work things out here and not there. >>> >>> Please take it as a compliment rather than as offence :-) >>> >>>> Also, FreeBSD is just one of the BSD descendants, and all of them share >>>> the libutil. >>> So, I take it that the change I'm proposing could have disruptive effects. >>> >>> I do think there are long-term advantages for FreeBSD and the other >>> BSD descendants in making it easy for their APIs to be deployed >>> elsewhere. I mean, in terms of portability. >>> >>> However I'm clearly biased so I'd rather not insist on this. I leave >>> it for you to judge. >> Renaming the libutil would break the ABI of the base system. >> If you are introducing new interfaces to the other systems, you >> can use a library name you find suitable. But for the library >> which is linked with significant number of existing binaries, >> rename is not an easy option. > Can we use libmap.conf to create an alias for the new name on FreeBSD so that programs that link against libbsdutil, to pick an arbitrary name, can work and libbsdutil can be packaged for debian? This will allow things to be portable, while allowing repackaging by Debian. That would be cool. +1 -- Alfred Perlstein VP Software Engineering, iXsystems From owner-freebsd-arch@FreeBSD.ORG Tue Jul 9 17:23: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 5D3EE759; Tue, 9 Jul 2013 17:23:45 +0000 (UTC) (envelope-from tijl@coosemans.org) Received: from mailrelay010.isp.belgacom.be (mailrelay010.isp.belgacom.be [195.238.6.177]) by mx1.freebsd.org (Postfix) with ESMTP id 7D7801E9B; Tue, 9 Jul 2013 17:23:44 +0000 (UTC) X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArwGAFdG3FFR8a/X/2dsb2JhbABagwkywWGBGBd0giMBAQVWIxALDgoJJQ8CKB4GDQEFAgEBEId/ukOPawcJg2kDkAuBLYdEkB+DEzo Received: from 215.175-241-81.adsl-dyn.isp.belgacom.be (HELO kalimero.tijl.coosemans.org) ([81.241.175.215]) by relay.skynet.be with ESMTP; 09 Jul 2013 19:23:37 +0200 Received: from kalimero.tijl.coosemans.org (kalimero.tijl.coosemans.org [127.0.0.1]) by kalimero.tijl.coosemans.org (8.14.7/8.14.7) with ESMTP id r69HNZ7I033404; Tue, 9 Jul 2013 19:23:36 +0200 (CEST) (envelope-from tijl@coosemans.org) Message-ID: <51DC4712.20707@coosemans.org> Date: Tue, 09 Jul 2013 19:23:30 +0200 From: Tijl Coosemans User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:17.0) Gecko/20130701 Thunderbird/17.0.7 MIME-Version: 1.0 To: Warner Losh Subject: Re: libutil in Debian References: <20130709113553.GP67810@FreeBSD.org> <20130709165939.GP91021@kib.kiev.ua> <0657575A-BF3A-486F-9582-C01E0FD97E38@bsdimp.com> In-Reply-To: <0657575A-BF3A-486F-9582-C01E0FD97E38@bsdimp.com> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----enig2GXHGOQFHUQPPXUJOBDRV" Cc: Konstantin Belousov , Gleb Smirnoff , Robert Millan , 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, 09 Jul 2013 17:23:45 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2GXHGOQFHUQPPXUJOBDRV Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2013-07-09 19:13, Warner Losh wrote: > On Jul 9, 2013, at 10:59 AM, Konstantin Belousov wrote: >> On Tue, Jul 09, 2013 at 05:05:00PM +0200, Robert Millan wrote: >>> 2013/7/9 Gleb Smirnoff : >>>> With all respect to GNU and Debian the libutil in BSD appeared in 19= 88, >>>> and the fact that GNU has taken that name in 1996 isn't reason for B= SD >>>> to change name. >>> >>> Thanks for pointing this out. >>> >>> Please note that my request is only based on practical grounds. It >>> shouldn't be interpreted as implying endorsement on Glibc's use of >>> libutil name. >>> >>> Historically, Glibc maintainer has been very difficult to deal with. >>> This has affected non-Linux ports of Glibc as well. In contrast, >>> FreeBSD community may or may not agree with proposals but is at least= >>> open to discuss things. This (rather than "fairness") is the reason I= >>> try to work things out here and not there. >>> >>> Please take it as a compliment rather than as offence :-) >>> >>>> Also, FreeBSD is just one of the BSD descendants, and all of them sh= are >>>> the libutil. >>> >>> So, I take it that the change I'm proposing could have disruptive eff= ects. >>> >>> I do think there are long-term advantages for FreeBSD and the other >>> BSD descendants in making it easy for their APIs to be deployed >>> elsewhere. I mean, in terms of portability. >>> >>> However I'm clearly biased so I'd rather not insist on this. I leave >>> it for you to judge. >> >> Renaming the libutil would break the ABI of the base system. >> If you are introducing new interfaces to the other systems, you >> can use a library name you find suitable. But for the library >> which is linked with significant number of existing binaries, >> rename is not an easy option. >=20 > Can we use libmap.conf to create an alias for the new name on FreeBSD > so that programs that link against libbsdutil, to pick an arbitrary > name, can work and libbsdutil can be packaged for debian? This will > allow things to be portable, while allowing repackaging by Debian. Or just a libbsdutil.so symlink? ------enig2GXHGOQFHUQPPXUJOBDRV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iF4EAREIAAYFAlHcRxcACgkQfoCS2CCgtit1IAD/RNS+KY9VQ+ojDRKX29XPWycY emkyrFEw+IHATWMhHeAA/38JnDcL1Nn8Uer5UYk2P/k5hBoeeJE5hM0S2dbtdBFz =v3Sw -----END PGP SIGNATURE----- ------enig2GXHGOQFHUQPPXUJOBDRV-- From owner-freebsd-arch@FreeBSD.ORG Tue Jul 9 17:27:32 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 24C7CA9C for ; Tue, 9 Jul 2013 17:27:32 +0000 (UTC) (envelope-from peter@wemm.org) Received: from mail-ve0-x235.google.com (mail-ve0-x235.google.com [IPv6:2607:f8b0:400c:c01::235]) by mx1.freebsd.org (Postfix) with ESMTP id D9BBB1F41 for ; Tue, 9 Jul 2013 17:27:31 +0000 (UTC) Received: by mail-ve0-f181.google.com with SMTP id db10so4765894veb.26 for ; Tue, 09 Jul 2013 10:27:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vB0QXQSErM9WJI5Dzdm81aZnx+73HkaH+Ubekq4HVoA=; b=yTR/gyjHZ9Quy99ZVGRfaOZ2haAss3aJDKdxeG7qAPljiXCBPjUNeXHSCy/C+0Ymba yZeFVOq/+WLSVwLlJ7G4dc5pGD7ctljBR83Wnddy4um5BDPf6ow1FjYOfwTbBY0H3SS+ gc52q2YDuMIrSFExOE1jzinH6NRNIVaf3i9Ag= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=vB0QXQSErM9WJI5Dzdm81aZnx+73HkaH+Ubekq4HVoA=; b=PgVPHN+WIecIpoLTVGBQ0DPPDCWfvVB/vURmjj5Dp3ExMa6vIn6hP1hUHU5NjJTxuw o9RICcnsYOAGh+EsACCHrfPntiKoB2TtMQpHKrSiGXJbtWkQiJsy3bqOM8ifYX0EzbFJ 1XvZu7eIU5uIOX8DRw/WepG+AGyfbwVz/nt8uRAnet7wwQ+dkxGa0jq7cQDCLS9yXg7M 7auZ1UEcxiNZjj+PVUjDi3YPvRKW68pm9mRZc7r7IuMzHKA8Va8g1OeA/yd2Y5Xbykk0 +yhkVfNYl0yWUZMpGTQI9xz8Gz1uQrnRl61f6dVkE7yCXMnoiusEyLfVNFQv34vLzP7F y3eA== MIME-Version: 1.0 X-Received: by 10.58.171.4 with SMTP id aq4mr16747838vec.26.1373390851415; Tue, 09 Jul 2013 10:27:31 -0700 (PDT) Received: by 10.221.37.198 with HTTP; Tue, 9 Jul 2013 10:27:31 -0700 (PDT) In-Reply-To: <51DC3A71.5040204@mu.org> References: <20130709113553.GP67810@FreeBSD.org> <51DC3A71.5040204@mu.org> Date: Tue, 9 Jul 2013 10:27:31 -0700 Message-ID: Subject: Re: libutil in Debian From: Peter Wemm To: Alfred Perlstein Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmV9jNQzELEPuGQJLuJrlyYC7itAtxJ/6i26NBoPsuu2g6o8EkxWlTDNpnsSnE2q+Wa1jJD Cc: freebsd-arch@freebsd.org, Gleb Smirnoff , Robert Millan 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, 09 Jul 2013 17:27:32 -0000 On Tue, Jul 9, 2013 at 9:29 AM, Alfred Perlstein wrote: > Maybe there's a way to make this work since our system is tightly > integrated. > > Have you looked at what happens with autoconf/automake? How bad does it > look from that PoV? Are there a ton of scripts that pull in libutil? Or is > that only a small portion of the base? There are a boatload of autoconf scripts that know libutil is where you get all the BSD bits. There's an extensive history here. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV UTF-8: So you can \342\200\231 .. for when a ' just won't do ZFS must be the bacon of file systems. "everything's better with ZFS" From owner-freebsd-arch@FreeBSD.ORG Tue Jul 9 17:34: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 0F441C01 for ; Tue, 9 Jul 2013 17:34:18 +0000 (UTC) (envelope-from peter@wemm.org) Received: from mail-ve0-x236.google.com (mail-ve0-x236.google.com [IPv6:2607:f8b0:400c:c01::236]) by mx1.freebsd.org (Postfix) with ESMTP id C20651FB4 for ; Tue, 9 Jul 2013 17:34:17 +0000 (UTC) Received: by mail-ve0-f182.google.com with SMTP id ox1so4911620veb.13 for ; Tue, 09 Jul 2013 10:34:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9QRbuqDHr4SNjlq7LCTjThjAEhLQp8HRz8MZsCzHWTU=; b=KD7b1ReiIh6O3n7sUI2nLp0Ba+mzFLJTFqqH7kz61UaudCDNT+n4vm7WfzzoFq45lv 0z+iHhf5ACeVlmkHFlEWcOENjoaKYFxxLzZEuGjHMFe/DAwov4NRPU4Wkk4NourvhWZr uqNqFxQfDdxCAJS8lCp3DGoij6vBTuN48mqs4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=9QRbuqDHr4SNjlq7LCTjThjAEhLQp8HRz8MZsCzHWTU=; b=LoONGn7B2V8kvib7Gke8wWTCLpBj2iG3EsQrEDlHeYW4nWcPHf0zluDFfMtebfLlpo CWHOnUo7WEjApqhM9K9zZegSzaaTL0Tzw46bq+AypPyvbNHT0BLPYT5wbM66ZGqHjGg3 aQZ3/mADz68Juqb7aLVj6XOs8X1RUhTExb0YBbLGclhb7wMCEbXeUFaTqLsaD3pndhO/ ShV1EzQa2H5YMGa8sCXb60GY4vmGehBWTi3pNkyvcj9r5II4oIOP9bDefDKGUefsWa7Z 4kJQzZH5IIvybL52Pp8x00CPNhnEK+cwd8bhaesMq1wx2lhyLfh+GKXr8TT2WNokgdqc IwWg== MIME-Version: 1.0 X-Received: by 10.220.47.131 with SMTP id n3mr17154732vcf.7.1373391257278; Tue, 09 Jul 2013 10:34:17 -0700 (PDT) Received: by 10.221.37.198 with HTTP; Tue, 9 Jul 2013 10:34:17 -0700 (PDT) In-Reply-To: <51DC4712.20707@coosemans.org> References: <20130709113553.GP67810@FreeBSD.org> <20130709165939.GP91021@kib.kiev.ua> <0657575A-BF3A-486F-9582-C01E0FD97E38@bsdimp.com> <51DC4712.20707@coosemans.org> Date: Tue, 9 Jul 2013 10:34:17 -0700 Message-ID: Subject: Re: libutil in Debian From: Peter Wemm To: Tijl Coosemans Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlcVoNaFFtZQ2C9otJ143k3Z8kTJ9kG7/uaYxCR5YzllFULEbiya258SV9DHf/kqc35qi9u Cc: Konstantin Belousov , freebsd-arch@freebsd.org, Gleb Smirnoff , Robert Millan 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, 09 Jul 2013 17:34:18 -0000 On Tue, Jul 9, 2013 at 10:23 AM, Tijl Coosemans wrote: > On 2013-07-09 19:13, Warner Losh wrote: >> On Jul 9, 2013, at 10:59 AM, Konstantin Belousov wrote: >>> On Tue, Jul 09, 2013 at 05:05:00PM +0200, Robert Millan wrote: >>>> 2013/7/9 Gleb Smirnoff : >>>>> With all respect to GNU and Debian the libutil in BSD appeared in 1988, >>>>> and the fact that GNU has taken that name in 1996 isn't reason for BSD >>>>> to change name. >>>> >>>> Thanks for pointing this out. >>>> >>>> Please note that my request is only based on practical grounds. It >>>> shouldn't be interpreted as implying endorsement on Glibc's use of >>>> libutil name. >>>> >>>> Historically, Glibc maintainer has been very difficult to deal with. >>>> This has affected non-Linux ports of Glibc as well. In contrast, >>>> FreeBSD community may or may not agree with proposals but is at least >>>> open to discuss things. This (rather than "fairness") is the reason I >>>> try to work things out here and not there. >>>> >>>> Please take it as a compliment rather than as offence :-) >>>> >>>>> Also, FreeBSD is just one of the BSD descendants, and all of them share >>>>> the libutil. >>>> >>>> So, I take it that the change I'm proposing could have disruptive effects. >>>> >>>> I do think there are long-term advantages for FreeBSD and the other >>>> BSD descendants in making it easy for their APIs to be deployed >>>> elsewhere. I mean, in terms of portability. >>>> >>>> However I'm clearly biased so I'd rather not insist on this. I leave >>>> it for you to judge. >>> >>> Renaming the libutil would break the ABI of the base system. >>> If you are introducing new interfaces to the other systems, you >>> can use a library name you find suitable. But for the library >>> which is linked with significant number of existing binaries, >>> rename is not an easy option. >> >> Can we use libmap.conf to create an alias for the new name on FreeBSD >> so that programs that link against libbsdutil, to pick an arbitrary >> name, can work and libbsdutil can be packaged for debian? This will >> allow things to be portable, while allowing repackaging by Debian. > > Or just a libbsdutil.so symlink? ld uses lib*.so ld-elf.so.1 uses the embedded DT_NEEDED that comes from the DT_SONAME embedded in the *.so files. Autoconf knows things like (a few random samples) checking for openpty() in -lutil checking for kvm_open in libutil checking for login_getclass() in -lutil While we could change the DT_SONAME, I don't see a way around "-lutil" without a lot of pain on our end. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV UTF-8: So you can \342\200\231 .. for when a ' just won't do ZFS must be the bacon of file systems. "everything's better with ZFS" From owner-freebsd-arch@FreeBSD.ORG Tue Jul 9 17:46: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 175A8DB5; Tue, 9 Jul 2013 17:46:00 +0000 (UTC) (envelope-from rmh.aybabtu@gmail.com) Received: from mail-qa0-x231.google.com (mail-qa0-x231.google.com [IPv6:2607:f8b0:400d:c00::231]) by mx1.freebsd.org (Postfix) with ESMTP id C3C121049; Tue, 9 Jul 2013 17:45:59 +0000 (UTC) Received: by mail-qa0-f49.google.com with SMTP id hu16so3076979qab.15 for ; Tue, 09 Jul 2013 10:45:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=/UhKR297argO1Xn0vzoOnKjxAzt0Y9IM28+A7Usyjvw=; b=NpqkLlFPGpPQvwCPlsPsBQYR/JBSTfP143SC1AKLrjdwbU0jOF0bjzb58U1VGqhJk/ v1/1wKfjv7xKQoq6SefaFBYc82fxktXc6dZ0UX9uO6TRaf1Q5P4STrTSyy8jBKH0UEfZ 0Ed+/YWLrV2ZfxebhWlnXuCr+YKewrvm6I2KYRO9taHKhP8Xb4EKHTB2tTq9aJGmIbQw tB+yuBppQUy1VtsXdwLHUofwLanu1KvquAUdHc/PyoOs/kcMFXxwI5HIoARE1yfzEvFk sQrvEDwlEJaWrC4gyjCC1VmBPVMYEeIhDzSz2uuxA9TVi2yH7pzzTSgkkYjQ/YauDR/m iWBQ== MIME-Version: 1.0 X-Received: by 10.224.165.77 with SMTP id h13mr14938794qay.58.1373391959344; Tue, 09 Jul 2013 10:45:59 -0700 (PDT) Sender: rmh.aybabtu@gmail.com Received: by 10.49.26.193 with HTTP; Tue, 9 Jul 2013 10:45:59 -0700 (PDT) Date: Tue, 9 Jul 2013 19:45:59 +0200 X-Google-Sender-Auth: kkd48eS5xMUJhALwhz_lIkYmn2U Message-ID: Subject: ABI change in libkvm (kvm_uread removal) From: Robert Millan To: Mikolaj Golub Content-Type: text/plain; charset=UTF-8 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: Tue, 09 Jul 2013 17:46:00 -0000 Hi Mikolaj, In 2011 you removed kvm_uread() from libkvm, in r227839. Was this an intentional ABI change? I notice that kvm.h public header still has the declaration. Also, the soname was not bumped. Should kvm.h and Makefile be adjusted to reflect the new ABI? -- Robert Millan From owner-freebsd-arch@FreeBSD.ORG Tue Jul 9 18: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 155AC573 for ; Tue, 9 Jul 2013 18:15:53 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-oa0-f46.google.com (mail-oa0-f46.google.com [209.85.219.46]) by mx1.freebsd.org (Postfix) with ESMTP id D282E11C6 for ; Tue, 9 Jul 2013 18:15:52 +0000 (UTC) Received: by mail-oa0-f46.google.com with SMTP id h1so8355704oag.19 for ; Tue, 09 Jul 2013 11:15:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=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=P8bUaKFUoeuTyXRlwo4lyOy4JGfIGvJfL7Ry7hYNT2E=; b=T3x0KxtAXw7D1P65/u6x+mjSPvXZ/WJoM3m0IWX2DDSBnEiPIyu0zT6PGbZI4Y0uiY j5AQap8FC8lRfX2wtY0Z4q/lYXqZbf39hcwFx78suePfgC0Hk0iCXORssEQ3yj2iufeG fWcVxyf0a8XKIfiZ23OwyaJCfXXa5Mq9M6DwdHhraDtkIEe2wUaJdE34upUtl5sMc0zi MlpytrWQF7Ad+dIZgvxQFDg1If1aLTnmozq4tu6s/LiyKHZo2BsWADRLVz+BR6Y9bdDI 4v4qJr9UXW5EAA1poS39zb3Zmmu35vYycnYxFVlRORH0dUzdUM5n8RuryNr8bj0MFBU+ ZWpg== X-Received: by 10.182.87.73 with SMTP id v9mr25048413obz.90.1373393752420; Tue, 09 Jul 2013 11:15:52 -0700 (PDT) Received: from monkey-bot.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPSA id fk3sm39370942obb.2.2013.07.09.11.15.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Jul 2013 11:15:51 -0700 (PDT) Sender: Warner Losh Subject: Re: libutil in Debian Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Tue, 9 Jul 2013 12:15:50 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <6E057FD0-9054-44CD-A806-3AFD8A7196CC@bsdimp.com> References: <20130709113553.GP67810@FreeBSD.org> <20130709165939.GP91021@kib.kiev.ua> <0657575A-BF3A-486F-9582-C01E0FD97E38@bsdimp.com> <51DC4712.20707@coosemans.org> To: Peter Wemm X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQmUO8Lo+gC5Vwy+EnG0rmynae4oJyUCB5E5133OaTGe+POuzDNTaM5Ez8dFfAHgRu8IJYOb Cc: Konstantin Belousov , freebsd-arch@freebsd.org, Tijl Coosemans , Gleb Smirnoff , Robert Millan 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, 09 Jul 2013 18:15:53 -0000 On Jul 9, 2013, at 11:34 AM, Peter Wemm wrote: > On Tue, Jul 9, 2013 at 10:23 AM, Tijl Coosemans = wrote: >> On 2013-07-09 19:13, Warner Losh wrote: >>> On Jul 9, 2013, at 10:59 AM, Konstantin Belousov wrote: >>>> On Tue, Jul 09, 2013 at 05:05:00PM +0200, Robert Millan wrote: >>>>> 2013/7/9 Gleb Smirnoff : >>>>>> With all respect to GNU and Debian the libutil in BSD appeared in = 1988, >>>>>> and the fact that GNU has taken that name in 1996 isn't reason = for BSD >>>>>> to change name. >>>>>=20 >>>>> Thanks for pointing this out. >>>>>=20 >>>>> Please note that my request is only based on practical grounds. It >>>>> shouldn't be interpreted as implying endorsement on Glibc's use of >>>>> libutil name. >>>>>=20 >>>>> Historically, Glibc maintainer has been very difficult to deal = with. >>>>> This has affected non-Linux ports of Glibc as well. In contrast, >>>>> FreeBSD community may or may not agree with proposals but is at = least >>>>> open to discuss things. This (rather than "fairness") is the = reason I >>>>> try to work things out here and not there. >>>>>=20 >>>>> Please take it as a compliment rather than as offence :-) >>>>>=20 >>>>>> Also, FreeBSD is just one of the BSD descendants, and all of them = share >>>>>> the libutil. >>>>>=20 >>>>> So, I take it that the change I'm proposing could have disruptive = effects. >>>>>=20 >>>>> I do think there are long-term advantages for FreeBSD and the = other >>>>> BSD descendants in making it easy for their APIs to be deployed >>>>> elsewhere. I mean, in terms of portability. >>>>>=20 >>>>> However I'm clearly biased so I'd rather not insist on this. I = leave >>>>> it for you to judge. >>>>=20 >>>> Renaming the libutil would break the ABI of the base system. >>>> If you are introducing new interfaces to the other systems, you >>>> can use a library name you find suitable. But for the library >>>> which is linked with significant number of existing binaries, >>>> rename is not an easy option. >>>=20 >>> Can we use libmap.conf to create an alias for the new name on = FreeBSD >>> so that programs that link against libbsdutil, to pick an arbitrary >>> name, can work and libbsdutil can be packaged for debian? This will >>> allow things to be portable, while allowing repackaging by Debian. >>=20 >> Or just a libbsdutil.so symlink? >=20 > ld uses lib*.so > ld-elf.so.1 uses the embedded DT_NEEDED that comes from the DT_SONAME > embedded in the *.so files. >=20 > Autoconf knows things like (a few random samples) > checking for openpty() in -lutil > checking for kvm_open in libutil > checking for login_getclass() in -lutil >=20 > While we could change the DT_SONAME, I don't see a way around "-lutil" > without a lot of pain on our end. We would continue to install libutil.*, so that solves all these = problems. We'd just provide a compatibility thing that allows one to = link with -lbsduitl also. I'm not sure that a symlink would actually work, but if it does, that's = an easy way around the problem. Warner From owner-freebsd-arch@FreeBSD.ORG Tue Jul 9 18:59:25 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 ECD143FB; Tue, 9 Jul 2013 18:59:25 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-ea0-x231.google.com (mail-ea0-x231.google.com [IPv6:2a00:1450:4013:c01::231]) by mx1.freebsd.org (Postfix) with ESMTP id 5B9C213AD; Tue, 9 Jul 2013 18:59:25 +0000 (UTC) Received: by mail-ea0-f177.google.com with SMTP id j14so4044623eak.36 for ; Tue, 09 Jul 2013 11:59:24 -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:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=K/cSb9hdiURvkwyE644sDeQmq7Mww0U0haGNN9tYkjQ=; b=m6b21uWlYehdRthqn9sA4vb8d6yTOJThYQCtmEZE60fTlWPgZuLFFbCoLQXuY2xuxj x8sR5G/8DjjzN8MV7UhgqhBl3inHVhRGfGHqPj9BUKKlGhdJ3Hn3m8/pHzPAt0+o+o3z TlV/6JVTiRXTbVd2H0aN2ii2RSWWMnbNVlMMZZpJo/HjTBBXl5tEr5USXwH1uLPBWKI7 BeczcWErIgUmCKPJsEDTBNa6JT7fr4iIY6i+kqq1nSW+bR3Az8ebeOIlDkbDHg4Z45Hc joThbBYk98SKksIt0qZdeax2dxgxxP1SOW5yWZWh+08cVmfdX6FcwXSjMIvvdSwhuoCa AN/g== X-Received: by 10.14.193.199 with SMTP id k47mr32126068een.83.1373396364357; Tue, 09 Jul 2013 11:59:24 -0700 (PDT) Received: from localhost ([178.150.115.244]) by mx.google.com with ESMTPSA id y1sm53338388eew.3.2013.07.09.11.59.22 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Tue, 09 Jul 2013 11:59:23 -0700 (PDT) Sender: Mikolaj Golub Date: Tue, 9 Jul 2013 21:59:19 +0300 From: Mikolaj Golub To: Robert Millan Subject: Re: ABI change in libkvm (kvm_uread removal) Message-ID: <20130709185846.GA19508@gmail.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: Tue, 09 Jul 2013 18:59:26 -0000 On Tue, Jul 09, 2013 at 07:45:59PM +0200, Robert Millan wrote: > Hi Mikolaj, > > In 2011 you removed kvm_uread() from libkvm, in r227839. > > Was this an intentional ABI change? I notice that kvm.h public header > still has the declaration. Also, the soname was not bumped. I think I thought then that kvm_uread() was for internal usage only (it was used by libkvm only for reading process args and env via procfs(5), no other consumers were found in base, no man page). Also reading from procfs(5) did not look like libkvm job, so after the last consumers had been removed, retiring it looked natural. I think I overlooked the declaration in kvm.h and that I might break ABI, otherwise it would have made me think more and ask other people if the removal was ok. > Should kvm.h and Makefile be adjusted to reflect the new ABI? Suggestions how this should be fixed properly (if possible) are highly appreciated. I will do what people suggest. -- Mikolaj Golub From owner-freebsd-arch@FreeBSD.ORG Tue Jul 9 19:10: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 6160CA06 for ; Tue, 9 Jul 2013 19:10:51 +0000 (UTC) (envelope-from peter@wemm.org) Received: from mail-vc0-x22a.google.com (mail-vc0-x22a.google.com [IPv6:2607:f8b0:400c:c03::22a]) by mx1.freebsd.org (Postfix) with ESMTP id 1C3171607 for ; Tue, 9 Jul 2013 19:10:51 +0000 (UTC) Received: by mail-vc0-f170.google.com with SMTP id hf12so4691345vcb.29 for ; Tue, 09 Jul 2013 12:10:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=a5mDNi+KYa7LPigqwtwuXuIINsfuB8RwytU5YWSKD14=; b=mBhiJnIcwVbM/st5m/7fs7CxiCV1V0VIu174oJbKwGDffE/q8bAl8CVV3W6MZ0AIRT oaCF44PN4z1TuZwQlO2EkAsgfiYq5SGYp4jsrlO7DXj7IGBN7asEdz5QkZmZuqZr9hio YUXEKdh2dLCY4zdnlUqRy6LrHk0C5NaydNjj0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=a5mDNi+KYa7LPigqwtwuXuIINsfuB8RwytU5YWSKD14=; b=XW+uAoxMiqDa75vO6B7FFteL1ZfE1kkMqFAuaENL0+mViAGUPfPibji3t4LN7jW3fH z0jnV8MWrRH+Lk3L/Hmtd7OWB1NMsxpMAlTy8XKpGSQuVgZyIjrKaoUy1fn/+W6Zx3BO KXYFQtlH8GhUyqcFiyRodtyJsCtKDnN+QQOzT1I5kHIqRcE7ch/Ma+6Y7B1TUfwFURrQ 5A3n6XV4PNb+RRQ92h2lBaCdlvwhX1UnA/taam1cVKfy660NbAIHVWWdCGw0TH8dY0cD i/xILVJKYTeRkKCj623i+JRuvqHAQkFzO2FUhxfEDiw1ynua38OKrbFXZhLpJZejSyQE OtvA== MIME-Version: 1.0 X-Received: by 10.52.24.133 with SMTP id u5mr6595585vdf.115.1373397050678; Tue, 09 Jul 2013 12:10:50 -0700 (PDT) Received: by 10.221.37.198 with HTTP; Tue, 9 Jul 2013 12:10:50 -0700 (PDT) In-Reply-To: <6E057FD0-9054-44CD-A806-3AFD8A7196CC@bsdimp.com> References: <20130709113553.GP67810@FreeBSD.org> <20130709165939.GP91021@kib.kiev.ua> <0657575A-BF3A-486F-9582-C01E0FD97E38@bsdimp.com> <51DC4712.20707@coosemans.org> <6E057FD0-9054-44CD-A806-3AFD8A7196CC@bsdimp.com> Date: Tue, 9 Jul 2013 12:10:50 -0700 Message-ID: Subject: Re: libutil in Debian From: Peter Wemm To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQl6/8GHaNILUq6nje81E6zkRTTwEnFIVjgqLQrf0utpzIjMOKpDPrGLYMExh2ZqSlo0+3aE Cc: Konstantin Belousov , freebsd-arch@freebsd.org, Tijl Coosemans , Gleb Smirnoff , Robert Millan 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, 09 Jul 2013 19:10:51 -0000 On Tue, Jul 9, 2013 at 11:15 AM, Warner Losh wrote: > On Jul 9, 2013, at 11:34 AM, Peter Wemm wrote: [..] >> While we could change the DT_SONAME, I don't see a way around "-lutil" >> without a lot of pain on our end. > > We would continue to install libutil.*, so that solves all these problems. We'd just provide a compatibility thing that allows one to link with -lbsduitl also. No, it'd have to be the other way around I think. We *need* -lutil to work forever. It was hard enough getting people to look in there in the first place and now there's a ton of released tarballs with it baked in. It's been hard enough to get people to fix freebsd-1* vs freebsd-1.* in autoconf. The DT_SONAME would solve a runtime ld-elf.so.1 compatability problem if glibc happens to name its libutil.so.N the same as ours. However I don't remember glibc using the same numbering conventions as us (they seem to like major.minor.micro while we have major only.. if I recall correctly) so even that shouldn't be an issue. > I'm not sure that a symlink would actually work, but if it does, that's an easy way around the problem. To be clear, *we* don't have a problem with the status quo. The change breaks a bunch of stuff and I'm not sure what we gain from it. What does glibc put in its libutil? Is it meant to be a bsdish-libutil compatability API? or something completely different? How did this even happen in the first place? I'd like to understand what exactly it is we're being asked to work around.. For example, if glibc ships a bsd-ish subset of libutil and we rename ours to something other than libutil, then wouldn't that make us incompatible with the convention we started and glibc picked up? -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV UTF-8: So you can \342\200\231 .. for when a ' just won't do From owner-freebsd-arch@FreeBSD.ORG Tue Jul 9 19:21: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 A19DD245; Tue, 9 Jul 2013 19:21:51 +0000 (UTC) (envelope-from rmh.aybabtu@gmail.com) Received: from mail-qa0-x232.google.com (mail-qa0-x232.google.com [IPv6:2607:f8b0:400d:c00::232]) by mx1.freebsd.org (Postfix) with ESMTP id 55D3616FB; Tue, 9 Jul 2013 19:21:51 +0000 (UTC) Received: by mail-qa0-f50.google.com with SMTP id l18so3108656qak.2 for ; Tue, 09 Jul 2013 12:21:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=CHkKYEpwAGR36afBxw6MHDi6Ehro6yflryzERnC8Smg=; b=w3sxDD1pYxhTnS5QerlVX4DrfVSx2+9lkelneLfxfmBh+wcFcfjdhVG6s4xR8DHab4 KvOaFCMN5ulVvHETfqDPVmdDrsiy/GKsE8nsBZgVx9oYbMd9WasyxO1ZBcPLgFFStmlL exOtpfJoA2hACwdldZAfxiPzojrS6XBadgcwaoa3NOSK8K9aFNg/Vjz6+S8VBz8/4DMl dMEv4ql8oujhHN5g5j+Dj5p9RvPVZlel1kK2gRFQYp5uJJWWt+dXjfAJp2e2SCgBNT5g FBvdvTU1c/cpc/+SjHbK0wmzDOb5ks0OE8Pj2h+2QijubwgZzJ8e1b2WuH5qmn8NSc51 GOaQ== MIME-Version: 1.0 X-Received: by 10.49.58.70 with SMTP id o6mr21791416qeq.1.1373397710892; Tue, 09 Jul 2013 12:21:50 -0700 (PDT) Sender: rmh.aybabtu@gmail.com Received: by 10.49.26.193 with HTTP; Tue, 9 Jul 2013 12:21:50 -0700 (PDT) In-Reply-To: <51DC4712.20707@coosemans.org> References: <20130709113553.GP67810@FreeBSD.org> <20130709165939.GP91021@kib.kiev.ua> <0657575A-BF3A-486F-9582-C01E0FD97E38@bsdimp.com> <51DC4712.20707@coosemans.org> Date: Tue, 9 Jul 2013 21:21:50 +0200 X-Google-Sender-Auth: zv3l1_ZMIwVvPjdFy_y5_FsnTo4 Message-ID: Subject: Re: libutil in Debian From: Robert Millan To: Tijl Coosemans Content-Type: text/plain; charset=UTF-8 Cc: Konstantin Belousov , Gleb Smirnoff , 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, 09 Jul 2013 19:21:51 -0000 2013/7/9 Tijl Coosemans : > > Or just a libbsdutil.so symlink? Works for me. A symlink would allow us to rename the library in a way that doesn't break compatibility with FreeBSD. Does this solution make everyone happy? -- Robert Millan From owner-freebsd-arch@FreeBSD.ORG Tue Jul 9 19:25:38 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B8C5337D; Tue, 9 Jul 2013 19:25:38 +0000 (UTC) (envelope-from rmh.aybabtu@gmail.com) Received: from mail-qc0-x231.google.com (mail-qc0-x231.google.com [IPv6:2607:f8b0:400d:c01::231]) by mx1.freebsd.org (Postfix) with ESMTP id 69BB71734; Tue, 9 Jul 2013 19:25:38 +0000 (UTC) Received: by mail-qc0-f177.google.com with SMTP id n1so3151459qcx.22 for ; Tue, 09 Jul 2013 12:25:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=4f41c68Mnk+8ioHfVDVOe/uKtF63ce26dTmJ6AuS0lQ=; b=dkgDn+cGmd2/5ngokHxKdEv/YntCkmgQx/V0H9FXXiMEnMHoM+vwy0IqQSu+/LkRlo m2XoTgzm5HcIITVeCvrKofJpCBPcMaPjArof5sbbiyRmkKcrdCEY0l2OBw+WBgfEjU7S FpJxZopeqAKY6MJjg9wJQ0P/qS71nMv+mpOn8s4W+JoPLk8MHMdto6K7UA6CfJXGB9io uRN+8Y9a8OlEf687xA8VzXmSvTPk1Cg20FsUS0rWS87WV30nHKWdhvBTGN44amqFZey/ bP5QESGPeRGDdfIfmZlbslJsLHKCyuCtyUotR4fpkNgeFIrNKjWCapXlggLUBrfjXUa2 RV6g== MIME-Version: 1.0 X-Received: by 10.224.74.1 with SMTP id s1mr25019450qaj.25.1373397937934; Tue, 09 Jul 2013 12:25:37 -0700 (PDT) Sender: rmh.aybabtu@gmail.com Received: by 10.49.26.193 with HTTP; Tue, 9 Jul 2013 12:25:37 -0700 (PDT) In-Reply-To: References: <20130709113553.GP67810@FreeBSD.org> <20130709165939.GP91021@kib.kiev.ua> <0657575A-BF3A-486F-9582-C01E0FD97E38@bsdimp.com> <51DC4712.20707@coosemans.org> <6E057FD0-9054-44CD-A806-3AFD8A7196CC@bsdimp.com> Date: Tue, 9 Jul 2013 21:25:37 +0200 X-Google-Sender-Auth: HV1fW0pk8mERAxkcLq5Qfj9atM4 Message-ID: Subject: Re: libutil in Debian From: Robert Millan To: Peter Wemm Content-Type: text/plain; charset=UTF-8 Cc: Konstantin Belousov , Tijl Coosemans , Gleb Smirnoff , 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, 09 Jul 2013 19:25:38 -0000 (not that this matters if the symlink option is adopted, but anyway, for your curiosity...) 2013/7/9 Peter Wemm : > What does glibc put in its libutil? Is it meant to be a bsdish-libutil > compatability API? or something completely different? How did this > even happen in the first place? It begun as libbsd, and it included a bunch of BSDish compatibility stuff. Then I think it was renamed to libbsd-compat at some point. And it was finally renamed to libutil. I think that's as the history goes. Mind that I didn't live through it, just derived this information by means of archaeology. From owner-freebsd-arch@FreeBSD.ORG Tue Jul 9 19:51:39 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 A8916BA4 for ; Tue, 9 Jul 2013 19:51:39 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-oa0-f47.google.com (mail-oa0-f47.google.com [209.85.219.47]) by mx1.freebsd.org (Postfix) with ESMTP id 70844188D for ; Tue, 9 Jul 2013 19:51:39 +0000 (UTC) Received: by mail-oa0-f47.google.com with SMTP id m1so8477914oag.6 for ; Tue, 09 Jul 2013 12:51:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=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=BInQdh3Ef5s4hKjV5wr9XbqaVKnW33r7ZFNAwDHhXHs=; b=bVqEYmsxie58H4ukb1TdEhQHnmLZ7oWCZTqgMNmXmTB1INoVFLiBOVFRL1yMgLIBDh hSmBQ1tA3vs20HMsIqwnu1xfjYi5F0Bp8cl5AV1okAp7uNYy3xMOlFErLOvNRrLzUypa q+wqVr6R9FMGkxEI1KyNp7Siap1GyM9+I4wb/ooy0aRtE0AqHj/dgTdUUwlM3UfjXaLG IQJJHYpq1SkKpzEOA6AdeLOa9YP7klu67/YI3RbQOG998KAGa20K8FIXUNwGcsOmaU8U /66LKsVqmebNaQdgJy/bShKLEvIf7IVg59/aXt8NVrbbMFwHQmBzM9yu45tPtezo52Fi gOHA== X-Received: by 10.182.55.72 with SMTP id q8mr25416515obp.96.1373399493058; Tue, 09 Jul 2013 12:51:33 -0700 (PDT) Received: from monkey-bot.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPSA id r4sm40501834oem.3.2013.07.09.12.51.31 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Jul 2013 12:51:32 -0700 (PDT) Sender: Warner Losh Subject: Re: libutil in Debian Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Tue, 9 Jul 2013 13:51:30 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130709113553.GP67810@FreeBSD.org> <20130709165939.GP91021@kib.kiev.ua> <0657575A-BF3A-486F-9582-C01E0FD97E38@bsdimp.com> <51DC4712.20707@coosemans.org> <6E057FD0-9054-44CD-A806-3AFD8A7196CC@bsdimp.com> To: Peter Wemm X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQkUd9/WZ2COgudbpQ/EiqpAXzeQ0Crx1beL7NP28uZhPeIwBK3eiwK8UwEL/U/WQrJSEytN Cc: Konstantin Belousov , freebsd-arch@freebsd.org, Tijl Coosemans , Gleb Smirnoff , Robert Millan 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, 09 Jul 2013 19:51:39 -0000 On Jul 9, 2013, at 1:10 PM, Peter Wemm wrote: > On Tue, Jul 9, 2013 at 11:15 AM, Warner Losh wrote: >> On Jul 9, 2013, at 11:34 AM, Peter Wemm wrote: > [..] >>> While we could change the DT_SONAME, I don't see a way around = "-lutil" >>> without a lot of pain on our end. >>=20 >> We would continue to install libutil.*, so that solves all these = problems. We'd just provide a compatibility thing that allows one to = link with -lbsduitl also. >=20 > No, it'd have to be the other way around I think. We *need* -lutil to > work forever. It was hard enough getting people to look in there in > the first place and now there's a ton of released tarballs with it > baked in. It's been hard enough to get people to fix freebsd-1* vs > freebsd-1.* in autoconf. >=20 > The DT_SONAME would solve a runtime ld-elf.so.1 compatability problem > if glibc happens to name its libutil.so.N the same as ours. However I > don't remember glibc using the same numbering conventions as us (they > seem to like major.minor.micro while we have major only.. if I recall > correctly) so even that shouldn't be an issue. I'm not proposing we change what we're doing today, apart from adding a = new name. >> I'm not sure that a symlink would actually work, but if it does, = that's an easy way around the problem. >=20 > To be clear, *we* don't have a problem with the status quo. The > change breaks a bunch of stuff and I'm not sure what we gain from it. >=20 > What does glibc put in its libutil? Is it meant to be a bsdish-libutil > compatability API? or something completely different? How did this > even happen in the first place? I'd like to understand what exactly > it is we're being asked to work around.. >=20 > For example, if glibc ships a bsd-ish subset of libutil and we rename > ours to something other than libutil, then wouldn't that make us > incompatible with the convention we started and glibc picked up? I'm not proposing a rename as a way to address this. Warner > --=20 > Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; = KI6FJV > UTF-8: So you can \342\200\231 .. for when a ' just won't do From owner-freebsd-arch@FreeBSD.ORG Tue Jul 9 20:15:40 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 8FA18335; Tue, 9 Jul 2013 20:15:40 +0000 (UTC) (envelope-from rmh.aybabtu@gmail.com) Received: from mail-qc0-x22b.google.com (mail-qc0-x22b.google.com [IPv6:2607:f8b0:400d:c01::22b]) by mx1.freebsd.org (Postfix) with ESMTP id 46ECB19E9; Tue, 9 Jul 2013 20:15:40 +0000 (UTC) Received: by mail-qc0-f171.google.com with SMTP id n1so3280742qcw.30 for ; Tue, 09 Jul 2013 13:15:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=pwfp/TdxAcH2OzNkEHniJWMvm85ADAgzvuMzKsrvD0o=; b=GT6R7DbhoNmdl30LCLODKxPz7Iq7TFhA7d7Qv9HpZ9sIiz+dPLuYslP9V0VfIRiA+7 Gky0e+BV7JAmEzDPkskAhM9963MQRcP99kiziUm6Tu2PtAVWF+CUg8Pend6pk0hywXZm Hs1VKpS9oY6F5mPkSK3U8HoHgXeVBnm4SDZKGdZF/bZgSp0bzNg8SxzkAEx94Hmc4rrX qC8B95z+XDCxMMvW6mTR3D9elTIRpgUj8oVivsdqhCUjzq2atb2l/jxUdQEqOgkYp8Jn FKvklURoUy77sgkyRsrXMsL5Gg5QsFj7gPEsnpH0afaMq9liC9SsVJ6wF/viDlKTg0Br yHcw== MIME-Version: 1.0 X-Received: by 10.224.98.140 with SMTP id q12mr24863469qan.99.1373400939807; Tue, 09 Jul 2013 13:15:39 -0700 (PDT) Sender: rmh.aybabtu@gmail.com Received: by 10.49.26.193 with HTTP; Tue, 9 Jul 2013 13:15:39 -0700 (PDT) In-Reply-To: <20130709185846.GA19508@gmail.com> References: <20130709185846.GA19508@gmail.com> Date: Tue, 9 Jul 2013 22:15:39 +0200 X-Google-Sender-Auth: B11NHq5Cg-C2H12VGl1hQ-B9YgM Message-ID: Subject: Re: ABI change in libkvm (kvm_uread removal) From: Robert Millan To: Mikolaj Golub Content-Type: text/plain; charset=UTF-8 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: Tue, 09 Jul 2013 20:15:40 -0000 2013/7/9 Mikolaj Golub : > I think I thought then that kvm_uread() was for internal usage only > (it was used by libkvm only for reading process args and env via > procfs(5), no other consumers were found in base, no man page). Also > reading from procfs(5) did not look like libkvm job, so after the last > consumers had been removed, retiring it looked natural. I think I > overlooked the declaration in kvm.h and that I might break ABI, > otherwise it would have made me think more and ask other people if the > removal was ok. Well I have no need for kvm_uread myself. In fact I don't even know what it does ;-) The ABI change was detected by Debian build tools during our upgrade to FreeBSD 9.1 codebase, which just means we will have to bump the soname. That is, unless you're planning to bring kvm_uread back? >> Should kvm.h and Makefile be adjusted to reflect the new ABI? > > Suggestions how this should be fixed properly (if possible) are highly > appreciated. I will do what people suggest. If noone else wants it, I'd suggest to bump soname, MFC, and be done with it. -- Robert Millan From owner-freebsd-arch@FreeBSD.ORG Tue Jul 9 20:26: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 AF29F4A1 for ; Tue, 9 Jul 2013 20:26:15 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ob0-f174.google.com (mail-ob0-f174.google.com [209.85.214.174]) by mx1.freebsd.org (Postfix) with ESMTP id 7AB651A49 for ; Tue, 9 Jul 2013 20:26:15 +0000 (UTC) Received: by mail-ob0-f174.google.com with SMTP id wd20so7471406obb.5 for ; Tue, 09 Jul 2013 13:26:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=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=NeXA/YQSjtvYzil2Du13djzCLkNIK0hWGPMJEOIaJdY=; b=duxDBvLXKPbWKlIqlOcmiuIcpNex1E5dwI6vmybpuEPwMcGz0eQdCyFTjkqywXMHjw DVZRS+/NCtF6RZWYuS5E2UcCk4tfr/K5c5qwiR2PAVUYWXYqDfr6G53C+I8v+BVDK+pH ylGPeYpaGuadB9pHe9e4ojAsJkhyyPovl8nSJrkWQ3NUUPzCp3Hgp8PlbsdWiZhG4m0P PQ5x6GPnMbVlQEbeBKiq6nJux9Ie7q2u+fyShAV0vu9nyTS0P0QTuqn4Y1eQbWNMm47v rOA2MHhR8h+ewF9PeaADKRK0X54YhsTKXxpIsdouiwVx1zT7D/ubzcKNglS8vzypOFnJ /rJg== X-Received: by 10.182.153.72 with SMTP id ve8mr25730078obb.39.1373401574587; Tue, 09 Jul 2013 13:26:14 -0700 (PDT) Received: from monkey-bot.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPSA id r4sm40661219oem.3.2013.07.09.13.26.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Jul 2013 13:26:13 -0700 (PDT) Sender: Warner Losh Subject: Re: ABI change in libkvm (kvm_uread removal) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Tue, 9 Jul 2013 14:26:11 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <47C53991-4D25-483D-A607-9F2983349481@bsdimp.com> References: <20130709185846.GA19508@gmail.com> To: Robert Millan X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQn3MIfPI+00P1o5J+AVUoMwnsqxuyI8iTWSfA5hvOHgEmbOqgTwaQeLC9I/Imin2hWOJpJ7 Cc: Mikolaj Golub , 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, 09 Jul 2013 20:26:15 -0000 On Jul 9, 2013, at 2:15 PM, Robert Millan wrote: > The ABI change was detected by Debian build tools during our upgrade > to FreeBSD 9.1 codebase, which just means we will have to bump the > soname. This is far more interesting than kvm_uread. How hard would it be to = somehow bring these tools into FreeBSD to run as part of our build = and/or release process? Warner From owner-freebsd-arch@FreeBSD.ORG Tue Jul 9 20:31: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 81592746 for ; Tue, 9 Jul 2013 20:31:28 +0000 (UTC) (envelope-from peter@wemm.org) Received: from mail-vb0-x22f.google.com (mail-vb0-x22f.google.com [IPv6:2607:f8b0:400c:c02::22f]) by mx1.freebsd.org (Postfix) with ESMTP id 3D2991AA3 for ; Tue, 9 Jul 2013 20:31:28 +0000 (UTC) Received: by mail-vb0-f47.google.com with SMTP id x14so4841569vbb.34 for ; Tue, 09 Jul 2013 13:31:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EjsfBgHg8SGM0ejBJYn34XhENm3zCU3rpu6hNLKLzjs=; b=K5mZka7h6vLS8sizl5sBD1gf/pHGkioZmmgo8+CW8nMZBdGswBSgihXMCANMrPF3Nk JTI207U7KgxUFOXvaESjyamhUk8dbNuOuq0P2ohCU/4KwfOhgu+CZmphu3RIj4gO6qEy xVm8Mk7b1qs33l3dkPMa0uFyKKhhnuFBybDeI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=EjsfBgHg8SGM0ejBJYn34XhENm3zCU3rpu6hNLKLzjs=; b=Q9QtJVxc4PToOjhlr0LTZtOXfGFRYs3BhfYjQC5kQasonS9KN9d38iXQUtFcyKkQM8 uTT+GTdf5uiAk80R/4xoPvL9ll7C6APpRb77j4+MLOEhDJnuIaE/zQL4/LmQEDP/AvxZ RzatOas0tYsL6tL4Bhye3jjixGw0hLodiR2qVeX+Ah8nZm7D+RaV0Pftm3v3vrvPqeqm UwO7TQCqPKgd+BvYAkAjUjhxtPTQpems+zrsB8GRqZ4s0LpA25qY0QUBueOvWxVvCJUH ziZZMerDYRpXE/B6IVE8BizBh6RvIzgQzJ5OBUaGk7YS6P4YRoIf/dUm7Bdvw2KiwH58 nK/Q== MIME-Version: 1.0 X-Received: by 10.52.92.16 with SMTP id ci16mr14079069vdb.88.1373401887756; Tue, 09 Jul 2013 13:31:27 -0700 (PDT) Received: by 10.221.37.198 with HTTP; Tue, 9 Jul 2013 13:31:27 -0700 (PDT) In-Reply-To: References: <20130709113553.GP67810@FreeBSD.org> <20130709165939.GP91021@kib.kiev.ua> <0657575A-BF3A-486F-9582-C01E0FD97E38@bsdimp.com> <51DC4712.20707@coosemans.org> <6E057FD0-9054-44CD-A806-3AFD8A7196CC@bsdimp.com> Date: Tue, 9 Jul 2013 13:31:27 -0700 Message-ID: Subject: Re: libutil in Debian From: Peter Wemm To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQng23lAfDxqNZvG1bz5K0FVGoiu7FNxWxKPAEVChoCtF1Bqsz87HBd7to8GKBvNA6aYdwF+ Cc: Konstantin Belousov , freebsd-arch@freebsd.org, Tijl Coosemans , Gleb Smirnoff , Robert Millan 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, 09 Jul 2013 20:31:28 -0000 On Tue, Jul 9, 2013 at 12:51 PM, Warner Losh wrote: > > On Jul 9, 2013, at 1:10 PM, Peter Wemm wrote: > >> On Tue, Jul 9, 2013 at 11:15 AM, Warner Losh wrote: >>> On Jul 9, 2013, at 11:34 AM, Peter Wemm wrote: >> [..] >>>> While we could change the DT_SONAME, I don't see a way around "-lutil" >>>> without a lot of pain on our end. >>> >>> We would continue to install libutil.*, so that solves all these problems. We'd just provide a compatibility thing that allows one to link with -lbsduitl also. >> >> No, it'd have to be the other way around I think. We *need* -lutil to >> work forever. It was hard enough getting people to look in there in >> the first place and now there's a ton of released tarballs with it >> baked in. It's been hard enough to get people to fix freebsd-1* vs >> freebsd-1.* in autoconf. >> >> The DT_SONAME would solve a runtime ld-elf.so.1 compatability problem >> if glibc happens to name its libutil.so.N the same as ours. However I >> don't remember glibc using the same numbering conventions as us (they >> seem to like major.minor.micro while we have major only.. if I recall >> correctly) so even that shouldn't be an issue. > > I'm not proposing we change what we're doing today, apart from adding a new name. Create a symlink from libbsdutil.so -> libutil.so and libbsdutil.a -> libutil.a and change nothing else, including keeping -lutil? I'm not entirely sure what that achieves, but it is harmless as far as I can see and creates no run-time ABI issues. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV UTF-8: So you can \342\200\231 .. for when a ' just won't do From owner-freebsd-arch@FreeBSD.ORG Tue Jul 9 20:45: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 3CA48CBD; Tue, 9 Jul 2013 20:45:04 +0000 (UTC) (envelope-from rmh.aybabtu@gmail.com) Received: from mail-qa0-x235.google.com (mail-qa0-x235.google.com [IPv6:2607:f8b0:400d:c00::235]) by mx1.freebsd.org (Postfix) with ESMTP id E15B61B6C; Tue, 9 Jul 2013 20:45:03 +0000 (UTC) Received: by mail-qa0-f53.google.com with SMTP id g10so3191660qah.12 for ; Tue, 09 Jul 2013 13:45:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=tIhTCseC5UlTgsEfXvtcqlHJ2jMJ6LKi+sHPMgROK98=; b=sX8oH3AL4fCIIHO3XbrJb57E19WDtSq4zRCve8HwOCEQylCQkd9IIZz/t/6ug74GHA P5bBevhdEl21MuV+3MDhWA+B6WsVHEqYSdJxqDgdvzgRxWgWneu0ORxpP8lIvYgwOz7B 1chmO2X1aW/EKAhvnvKcQ7UIKlvqDjKPthG8eTBXoo8MeC7g8X0hKg15nPdy3vWqr4Xi Szu528iHFWFipymSJxJh/YuF7uZmOU9YEyLLCJGbnexcC/e25y8mKVXFtlQFyRnjkRLn r0CSbalI4vOfF1tTeL17qfXfKVOkJrXVbiLlGjhIZlDYysHCwMUS+rX6AgHfrkioSZo3 73Tg== MIME-Version: 1.0 X-Received: by 10.224.165.77 with SMTP id h13mr15563635qay.58.1373402703531; Tue, 09 Jul 2013 13:45:03 -0700 (PDT) Sender: rmh.aybabtu@gmail.com Received: by 10.49.26.193 with HTTP; Tue, 9 Jul 2013 13:45:03 -0700 (PDT) In-Reply-To: References: <20130709113553.GP67810@FreeBSD.org> <20130709165939.GP91021@kib.kiev.ua> <0657575A-BF3A-486F-9582-C01E0FD97E38@bsdimp.com> <51DC4712.20707@coosemans.org> <6E057FD0-9054-44CD-A806-3AFD8A7196CC@bsdimp.com> Date: Tue, 9 Jul 2013 22:45:03 +0200 X-Google-Sender-Auth: 6lzQcUngydK8k1oFhGoFLQ_YLrM Message-ID: Subject: Re: libutil in Debian From: Robert Millan To: Peter Wemm Content-Type: text/plain; charset=UTF-8 Cc: Konstantin Belousov , Tijl Coosemans , Gleb Smirnoff , 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, 09 Jul 2013 20:45:04 -0000 2013/7/9 Peter Wemm : > Create a symlink from libbsdutil.so -> libutil.so and libbsdutil.a -> > libutil.a and change nothing else, including keeping -lutil? I'm not > entirely sure what that achieves, but it is harmless as far as I can > see and creates no run-time ABI issues. The problem is that right now, if we wanted to provide FreeBSD libutil in Debian we'd have to rename it. Of course we could just make up an arbitrary name and use that, but it would introduce a gratuitous divergence, and the reason we want libutil in first place is that we want to be more compatible with FreeBSD. -- Robert Millan From owner-freebsd-arch@FreeBSD.ORG Tue Jul 9 21:10:24 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 EB8C7C57; Tue, 9 Jul 2013 21:10:23 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-bk0-x22b.google.com (mail-bk0-x22b.google.com [IPv6:2a00:1450:4008:c01::22b]) by mx1.freebsd.org (Postfix) with ESMTP id 26E191CDA; Tue, 9 Jul 2013 21:10:22 +0000 (UTC) Received: by mail-bk0-f43.google.com with SMTP id jm2so2549748bkc.30 for ; Tue, 09 Jul 2013 14:10:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=+MpMjhBTryWXCNZwYb0JswSyAC/+bhNHwQ8r9Vvd+tc=; b=OwxSGOWS9GJG39WBN/XuObHKmqnjS/0ABNWVC95xQ4g0WoT+nBPtxBRpYvasbLB+r1 3QOcQDYtE95DX+taPG8fN7BUvIOTNKPJKaGXAcbAyEnf9uo50SjFQyb6kEAbqKPZZLHu grA1RDPWR2YBtdSPXEYj36wyuqEe7WqFEXLH7zEZ5wN5iJhOrEnCUBooKOjwWgAXmcaO R/sghldhGim9FYO7D2UkPAX6aL2bYbpHctdaJ4jV7GCz5fl93yTrUsVzmMjEnptGc6tq RUOhxU/kwiWZCh9PTBtlrySiSuAUozcVa/fqwgsW3n3QGkyf4ksUed0ifWrf8K4WZ/7R jULA== MIME-Version: 1.0 X-Received: by 10.204.66.133 with SMTP id n5mr4390249bki.38.1373404222256; Tue, 09 Jul 2013 14:10:22 -0700 (PDT) Sender: chmeeedalf@gmail.com Received: by 10.205.2.69 with HTTP; Tue, 9 Jul 2013 14:10:22 -0700 (PDT) In-Reply-To: References: <20130709113553.GP67810@FreeBSD.org> <20130709165939.GP91021@kib.kiev.ua> <0657575A-BF3A-486F-9582-C01E0FD97E38@bsdimp.com> <51DC4712.20707@coosemans.org> <6E057FD0-9054-44CD-A806-3AFD8A7196CC@bsdimp.com> Date: Tue, 9 Jul 2013 14:10:22 -0700 X-Google-Sender-Auth: oKIIyvPAT-oJUSQPNl-kYodMbEg Message-ID: Subject: Re: libutil in Debian From: Justin Hibbits To: Robert Millan Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Konstantin Belousov , Tijl Coosemans , Gleb Smirnoff , 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, 09 Jul 2013 21:10:24 -0000 On Tue, Jul 9, 2013 at 1:45 PM, Robert Millan wrote: > 2013/7/9 Peter Wemm : > > Create a symlink from libbsdutil.so -> libutil.so and libbsdutil.a -> > > libutil.a and change nothing else, including keeping -lutil? I'm not > > entirely sure what that achieves, but it is harmless as far as I can > > see and creates no run-time ABI issues. > > The problem is that right now, if we wanted to provide FreeBSD libutil > in Debian we'd have to rename it. Of course we could just make up an > arbitrary name and use that, but it would introduce a gratuitous > divergence, and the reason we want libutil in first place is that we > want to be more compatible with FreeBSD. > > -- > Robert Millan What about importing the necessary functions into the glibc libutil for Debian? This way it stays as libutil, and if glibc imports the functions to itself there's less to worry about. If glibc's libutil started out life as libbsdcompat, then I think it would be appropriate to merge as needed. - Justin From owner-freebsd-arch@FreeBSD.ORG Tue Jul 9 21:12:17 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 1ACD5D2F; Tue, 9 Jul 2013 21:12:17 +0000 (UTC) (envelope-from rmh.aybabtu@gmail.com) Received: from mail-qc0-x22e.google.com (mail-qc0-x22e.google.com [IPv6:2607:f8b0:400d:c01::22e]) by mx1.freebsd.org (Postfix) with ESMTP id C4A7E1CF3; Tue, 9 Jul 2013 21:12:16 +0000 (UTC) Received: by mail-qc0-f174.google.com with SMTP id m15so3237415qcq.5 for ; Tue, 09 Jul 2013 14:12:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=dTFNvMhR1DRL+WRVsfAdvjttodDgnITGdu+yqs/32XU=; b=OyZhMtma8iuL+gYy7CR0UrNF5QyQwovZRO0bc9z8gSfdY9/BLwPH8C/3PeU9HhQmeC Cqglfgasood2PXOmdIYg27Dlco5DTvzMqgzz/9ZeepeODB8566ZJYD/7s9RMZ7L9vMxu YA6ZPEejPNPUfX7StqMIvfZQIlsGlSUkJ+t2Uj7N12AhDtARBBhXuG+ThHdSxXL8yzQC nRutc+szAMbFxZcFvAs3H2HHMoVzW+HbmRncSZJBCZy9vIAJwU70MmZOVB9vHWWIBb3n VINspaFx9vJKQafji99A9a0tcjbNrUcetEjUAlJLqo5/5xnNTEBcbYV0lhWARufUgvuu nHPA== MIME-Version: 1.0 X-Received: by 10.49.58.70 with SMTP id o6mr22148291qeq.1.1373404336414; Tue, 09 Jul 2013 14:12:16 -0700 (PDT) Sender: rmh.aybabtu@gmail.com Received: by 10.49.26.193 with HTTP; Tue, 9 Jul 2013 14:12:16 -0700 (PDT) In-Reply-To: <47C53991-4D25-483D-A607-9F2983349481@bsdimp.com> References: <20130709185846.GA19508@gmail.com> <47C53991-4D25-483D-A607-9F2983349481@bsdimp.com> Date: Tue, 9 Jul 2013 23:12:16 +0200 X-Google-Sender-Auth: bHO0T1NNWyxf6t0Mo1mpvWUHHs4 Message-ID: Subject: Re: ABI change in libkvm (kvm_uread removal) From: Robert Millan To: Warner Losh Content-Type: text/plain; charset=UTF-8 Cc: Mikolaj Golub , 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, 09 Jul 2013 21:12:17 -0000 2013/7/9 Warner Losh : > This is far more interesting than kvm_uread. How hard would it be to somehow bring these tools into FreeBSD to run as part of our build and/or release process? We use a tool called dpkg-gensymbols to generate symbol lists, such as this one: http://anonscm.debian.org/viewvc/glibc-bsd/trunk/freebsd-libs/debian/libkvm0.symbols?revision=3971&view=markup Every time the code is built, result is compared with previously recorded list. If one of the previous symbols is missing, the build fails. I don't think the program itself may be useful outside of Debian, but perhaps you can take some ideas from it: http://anonscm.debian.org/gitweb/?p=dpkg/dpkg.git;a=blob;f=scripts/dpkg-gensymbols.pl;h=28a788da5ec89fff0b09efaff1a14457fa2eb0f7;hb=HEAD -- Robert Millan From owner-freebsd-arch@FreeBSD.ORG Tue Jul 9 21:17:14 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 A5E4CFAB; Tue, 9 Jul 2013 21:17:14 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (unknown [IPv6:2001:610:1108:5012::107]) by mx1.freebsd.org (Postfix) with ESMTP id 6B7831D20; Tue, 9 Jul 2013 21:17:14 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 3F8641203CF; Tue, 9 Jul 2013 23:16:58 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 1677) id E0AE828494; Tue, 9 Jul 2013 23:16:57 +0200 (CEST) Date: Tue, 9 Jul 2013 23:16:57 +0200 From: Jilles Tjoelker To: Mikolaj Golub Subject: Re: ABI change in libkvm (kvm_uread removal) Message-ID: <20130709211657.GA86400@stack.nl> References: <20130709185846.GA19508@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130709185846.GA19508@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-arch@freebsd.org, Robert Millan 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, 09 Jul 2013 21:17:14 -0000 On Tue, Jul 09, 2013 at 09:59:19PM +0300, Mikolaj Golub wrote: > On Tue, Jul 09, 2013 at 07:45:59PM +0200, Robert Millan wrote: > > In 2011 you removed kvm_uread() from libkvm, in r227839. > > Was this an intentional ABI change? I notice that kvm.h public header > > still has the declaration. Also, the soname was not bumped. > I think I thought then that kvm_uread() was for internal usage only > (it was used by libkvm only for reading process args and env via > procfs(5), no other consumers were found in base, no man page). Also > reading from procfs(5) did not look like libkvm job, so after the last > consumers had been removed, retiring it looked natural. I think I > overlooked the declaration in kvm.h and that I might break ABI, > otherwise it would have made me think more and ask other people if the > removal was ok. > > Should kvm.h and Makefile be adjusted to reflect the new ABI? > Suggestions how this should be fixed properly (if possible) are highly > appreciated. I will do what people suggest. I would suggest bringing back kvm_uread() in stable/9 so that the ABI is kept. In head, I suggest removing kvm_uread() from the header file and bumping the soname. I think MFCing the soname bump will cause more annoyance than the removal of kvm_uread() itself. Much of the code using libkvm uses it to access kernel internals, which are not a proper ABI/API and change fairly frequently. Therefore, it is probably acceptable for this library not to use symbol versioning. The functions that do not expose the caller to kernel internals like kvm_getprocs() should probably not be used; instead, libprocstat provides a more ABI-stable way to do the same. Calling the sysctls directly is also an option. -- Jilles Tjoelker From owner-freebsd-arch@FreeBSD.ORG Tue Jul 9 21:20: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 5ADD4423; Tue, 9 Jul 2013 21:20:14 +0000 (UTC) (envelope-from rmh.aybabtu@gmail.com) Received: from mail-qe0-x22a.google.com (mail-qe0-x22a.google.com [IPv6:2607:f8b0:400d:c02::22a]) by mx1.freebsd.org (Postfix) with ESMTP id 31AEC1D65; Tue, 9 Jul 2013 21:20:14 +0000 (UTC) Received: by mail-qe0-f42.google.com with SMTP id s14so3364287qeb.15 for ; Tue, 09 Jul 2013 14:20:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=tnhQ4eDkS+9PnvHX1ivpjdvkzjf7Saj2H2PqYOLW5Pc=; b=YBFspeJBAGjb1dmSza/jArt6NPAwQ6+/kPasoj0R4J16PaTJqs8li6pWhIcODgEa1a 3ViWnDu3PpgVWzvhVP4rtdjmLpU8gQEtnDDJBxosRpTSID+89jUNLXrmouqJFt76cT8+ 89EwQhzAdkWULvp8OlqEWQMwZ6AQdmdQguDUZPWlUlRWcFzfgmMy2xsy3m7D0YOOYnV5 o5/qODn2EwaJ9rtz2XmfGmyMCkKhKCMCRWx+R6HR1dYFZz+mZIuRk7aoKOaX9bXfDrzW pge116hu9T7DB0hgwsuA0J9CL/sb2EMy3015acEZ1kigCskW2gka8JpBUc3s9LLuBesE K2xA== MIME-Version: 1.0 X-Received: by 10.49.59.228 with SMTP id c4mr22557208qer.15.1373404813716; Tue, 09 Jul 2013 14:20:13 -0700 (PDT) Sender: rmh.aybabtu@gmail.com Received: by 10.49.26.193 with HTTP; Tue, 9 Jul 2013 14:20:13 -0700 (PDT) In-Reply-To: References: <20130709113553.GP67810@FreeBSD.org> <20130709165939.GP91021@kib.kiev.ua> <0657575A-BF3A-486F-9582-C01E0FD97E38@bsdimp.com> <51DC4712.20707@coosemans.org> <6E057FD0-9054-44CD-A806-3AFD8A7196CC@bsdimp.com> Date: Tue, 9 Jul 2013 23:20:13 +0200 X-Google-Sender-Auth: imw2XthQpFG6OueaQKOiBIRJBqQ Message-ID: Subject: Re: libutil in Debian From: Robert Millan To: Justin Hibbits Content-Type: text/plain; charset=UTF-8 Cc: Konstantin Belousov , Tijl Coosemans , Gleb Smirnoff , 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, 09 Jul 2013 21:20:15 -0000 2013/7/9 Justin Hibbits : > What about importing the necessary functions into the glibc libutil for > Debian? This way it stays as libutil, and if glibc imports the functions to > itself there's less to worry about. If glibc's libutil started out life as > libbsdcompat, then I think it would be appropriate to merge as needed. Even assuming they'd agree, which is unlikely, FSF would require copyright assignment paperwork, to be signed and physically mailed by each contributor. This would apply to future updates as well. The paper itself is no big deal (author retains the right to license the software under any terms they wish), but hunting down contributors to persuade them to sign the papers is definitely not what I had in mind when I started this thread ;-) -- Robert Millan From owner-freebsd-arch@FreeBSD.ORG Tue Jul 9 21:30:56 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 49DEAD52; Tue, 9 Jul 2013 21:30:56 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-bk0-x22a.google.com (mail-bk0-x22a.google.com [IPv6:2a00:1450:4008:c01::22a]) by mx1.freebsd.org (Postfix) with ESMTP id 766011E00; Tue, 9 Jul 2013 21:30:55 +0000 (UTC) Received: by mail-bk0-f42.google.com with SMTP id jk13so2599886bkc.29 for ; Tue, 09 Jul 2013 14:30:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=NOQG+xAgkhyY7qXatqaLiOD6QxL4oY03UQAiLCI2ucE=; b=zhYfMiZOVsdhq44PuZSVPRZnAOyaOEM+MIaPsQ6wXGc+4y7QpDbyzg3pa/30OZwKj4 K+4l2RunPls7BOpqvlFxIiwNYveSOk9Fh/ybkKk7tPRB1x6rC2CYJf8r0zIw1CLV3N6E 9esdqrQkv5kbYluGgcQwieT+UbEOkl3E5HCsrqLa7EGeTQe0hvxyOL8AYgAjZhxBhs5m P0epB4tfkcUHgsphTaMORAD92icp0mzs8oCwJH0tBTk7KHSsY7HPRXrjvVit3GVaYtC+ uM1yeOw87I3DyLGvkt4D+EwdeU6xPCO0Br08B7k0gxKvKGfVj1Z7nlOfRMyI1ygxOdlW TI2Q== MIME-Version: 1.0 X-Received: by 10.204.198.9 with SMTP id em9mr4303846bkb.131.1373405454330; Tue, 09 Jul 2013 14:30:54 -0700 (PDT) Sender: chmeeedalf@gmail.com Received: by 10.205.2.69 with HTTP; Tue, 9 Jul 2013 14:30:54 -0700 (PDT) In-Reply-To: References: <20130709113553.GP67810@FreeBSD.org> <20130709165939.GP91021@kib.kiev.ua> <0657575A-BF3A-486F-9582-C01E0FD97E38@bsdimp.com> <51DC4712.20707@coosemans.org> <6E057FD0-9054-44CD-A806-3AFD8A7196CC@bsdimp.com> Date: Tue, 9 Jul 2013 14:30:54 -0700 X-Google-Sender-Auth: g9drUccFXo_XAWdfrl_N_HWp_KY Message-ID: Subject: Re: libutil in Debian From: Justin Hibbits To: Robert Millan Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Konstantin Belousov , Tijl Coosemans , Gleb Smirnoff , 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, 09 Jul 2013 21:30:56 -0000 On Tue, Jul 9, 2013 at 2:20 PM, Robert Millan wrote: > 2013/7/9 Justin Hibbits : > > What about importing the necessary functions into the glibc libutil for > > Debian? This way it stays as libutil, and if glibc imports the > functions to > > itself there's less to worry about. If glibc's libutil started out life > as > > libbsdcompat, then I think it would be appropriate to merge as needed. > > Even assuming they'd agree, which is unlikely, FSF would require > copyright assignment paperwork, to be signed and physically mailed by > each contributor. This would apply to future updates as well. > > The paper itself is no big deal (author retains the right to license > the software under any terms they wish), but hunting down contributors > to persuade them to sign the papers is definitely not what I had in > mind when I started this thread ;-) > > -- > Robert Millan > I was thinking more in terms of adding the functions to the debian local patch set. I don't know how intrusive it would be, but it may be worth looking into. - Justin From owner-freebsd-arch@FreeBSD.ORG Tue Jul 9 21:32:39 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 61E96124; Tue, 9 Jul 2013 21:32:39 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by mx1.freebsd.org (Postfix) with ESMTP id 3F7091E1B; Tue, 9 Jul 2013 21:32:39 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.6/8.14.6) with ESMTP id r69LWZMJ055386; Tue, 9 Jul 2013 14:32:35 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.6/8.14.6/Submit) id r69LWZRp055385; Tue, 9 Jul 2013 14:32:35 -0700 (PDT) (envelope-from sgk) Date: Tue, 9 Jul 2013 14:32:35 -0700 From: Steve Kargl To: Robert Millan Subject: Re: libutil in Debian Message-ID: <20130709213235.GA32425@troutmask.apl.washington.edu> References: <0657575A-BF3A-486F-9582-C01E0FD97E38@bsdimp.com> <51DC4712.20707@coosemans.org> <6E057FD0-9054-44CD-A806-3AFD8A7196CC@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Konstantin Belousov , Justin Hibbits , Tijl Coosemans , Gleb Smirnoff , 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, 09 Jul 2013 21:32:39 -0000 On Tue, Jul 09, 2013 at 11:20:13PM +0200, Robert Millan wrote: > 2013/7/9 Justin Hibbits : > > What about importing the necessary functions into the glibc libutil for > > Debian? This way it stays as libutil, and if glibc imports the functions to > > itself there's less to worry about. If glibc's libutil started out life as > > libbsdcompat, then I think it would be appropriate to merge as needed. > > Even assuming they'd agree, which is unlikely, FSF would require > copyright assignment paperwork, to be signed and physically mailed by > each contributor. This would apply to future updates as well. > > The paper itself is no big deal (author retains the right to license > the software under any terms they wish), but hunting down contributors > to persuade them to sign the papers is definitely not what I had in > mind when I started this thread ;-) > The FSF cannot stop Debian from importing the FreeBSD code into Debian's libutil tree. There needs to be no asignment of copyright. -- Steve From owner-freebsd-arch@FreeBSD.ORG Tue Jul 9 21:50: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 6280ABE0 for ; Tue, 9 Jul 2013 21:50:26 +0000 (UTC) (envelope-from peter@wemm.org) Received: from mail-vb0-x233.google.com (mail-vb0-x233.google.com [IPv6:2607:f8b0:400c:c02::233]) by mx1.freebsd.org (Postfix) with ESMTP id 223261F14 for ; Tue, 9 Jul 2013 21:50:26 +0000 (UTC) Received: by mail-vb0-f51.google.com with SMTP id x17so4859242vbf.10 for ; Tue, 09 Jul 2013 14:50:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LfikC9wXtAMYHguI/xPWlIo9OzzgTp72ySFg5xwojKg=; b=UFgNk13LV8hkYaHEFrd9LFoaHjZtGdKf0mOgSBOTh3Uphno83LCE8+icxvmoDILqwx 0texReOLYdFD/bFkM+09wLkSieVKTGQ8BA0u7wYnPo5wMOkJhgR24+w4hoZr1f/KslDo nGPqNXfngut5QRpaQ6lqBdzFepK5pe2jaA8h8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=LfikC9wXtAMYHguI/xPWlIo9OzzgTp72ySFg5xwojKg=; b=LTS1PBIU74aPxq/h2eSjRhgVn/99V9AZ+hDDGK4YiykqCPRCYNLAZDcsRFnUXPzDsC nt3+YFXCB9yYReN9IbIbQBJeDraxUbbagGG+RuH9YgeC0kBxudVthuXsIz4dZ9P13Z/6 0zxbBa87DI+ehHyjStY5D+pAAu2chpOjDYuoMQNzhm+CxhqlIB2sg9SNij+spxsvAsCo 9R6HQebj3vvBIk7Acfu6OByCkyzLUPubl+SzeNN2HH9sm6GtHur7qu6lzDcAoe4Dcvd7 hyyGGECyVgy9bAQPgjp8Wgt4a0jPTzB7of24/NELtRi+zaL2E7SlWmKm78VemO/PrkMT r2OQ== MIME-Version: 1.0 X-Received: by 10.58.2.137 with SMTP id 9mr17815258veu.50.1373406625603; Tue, 09 Jul 2013 14:50:25 -0700 (PDT) Received: by 10.221.37.198 with HTTP; Tue, 9 Jul 2013 14:50:25 -0700 (PDT) In-Reply-To: <20130709211657.GA86400@stack.nl> References: <20130709185846.GA19508@gmail.com> <20130709211657.GA86400@stack.nl> Date: Tue, 9 Jul 2013 14:50:25 -0700 Message-ID: Subject: Re: ABI change in libkvm (kvm_uread removal) From: Peter Wemm To: Jilles Tjoelker Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlsJUoZWf2AaSCjjuI/32LLfXGhLPrPUqQiSHO/M2zsCZ7ueWg8+s0rjBblvn2+U61nJiUt Cc: Mikolaj Golub , Robert Millan , 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, 09 Jul 2013 21:50:26 -0000 On Tue, Jul 9, 2013 at 2:16 PM, Jilles Tjoelker wrote: > On Tue, Jul 09, 2013 at 09:59:19PM +0300, Mikolaj Golub wrote: >> On Tue, Jul 09, 2013 at 07:45:59PM +0200, Robert Millan wrote: >> > In 2011 you removed kvm_uread() from libkvm, in r227839. > >> > Was this an intentional ABI change? I notice that kvm.h public header >> > still has the declaration. Also, the soname was not bumped. > >> I think I thought then that kvm_uread() was for internal usage only >> (it was used by libkvm only for reading process args and env via >> procfs(5), no other consumers were found in base, no man page). Also >> reading from procfs(5) did not look like libkvm job, so after the last >> consumers had been removed, retiring it looked natural. I think I >> overlooked the declaration in kvm.h and that I might break ABI, >> otherwise it would have made me think more and ask other people if the >> removal was ok. > >> > Should kvm.h and Makefile be adjusted to reflect the new ABI? > >> Suggestions how this should be fixed properly (if possible) are highly >> appreciated. I will do what people suggest. > > I would suggest bringing back kvm_uread() in stable/9 so that the ABI is > kept. In head, I suggest removing kvm_uread() from the header file and > bumping the soname. I think MFCing the soname bump will cause more > annoyance than the removal of kvm_uread() itself. kvm_uread() was a wrapper around /proc/$pid/mem, which obviously doesn't work with no procfs. It's been a while since I've seen a machine with /proc, it's off by default now, no? Anyway, all the debuggers (gdb etc) use ptrace. There really isn't any known outside consumer to test it with. We could write some test cases but that's akin to doing an exam with the answer sheet right next to you. We could restore symbol compatability with kvm_uread(...) { _kvm_err("kd, kd->program, "kvm_uread not implemented"); return (-1); } .. and restore the code later if we can actually find a legitimate user of it so we can actually test it? -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV UTF-8: So you can \342\200\231 .. for when a ' just won't do ZFS must be the bacon of file systems. "everything's better with ZFS" From owner-freebsd-arch@FreeBSD.ORG Tue Jul 9 22:48:52 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 244C29E for ; Tue, 9 Jul 2013 22:48:52 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from nibbler.fubar.geek.nz (nibbler.fubar.geek.nz [199.48.134.198]) by mx1.freebsd.org (Postfix) with ESMTP id 0AF7111E0 for ; Tue, 9 Jul 2013 22:48:51 +0000 (UTC) Received: from bender.Home (97e5f83b.skybroadband.com [151.229.248.59]) by nibbler.fubar.geek.nz (Postfix) with ESMTPSA id CA5675E1EF; Tue, 9 Jul 2013 22:48:44 +0000 (UTC) Date: Tue, 9 Jul 2013 23:48:37 +0100 From: Andrew Turner To: Warner Losh Subject: Re: Adding a MACHINE_ARCH note Message-ID: <20130709234837.559e3769@bender.Home> In-Reply-To: <32F979BD-FB5C-4111-9586-4C5E7C6DFA71@bsdimp.com> References: <20130709090744.0e497e7e@bender.Home> <32F979BD-FB5C-4111-9586-4C5E7C6DFA71@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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: Tue, 09 Jul 2013 22:48:52 -0000 On Tue, 9 Jul 2013 08:19:46 -0600 Warner Losh wrote: > I thought that the ELF headers gave us all the data we needed to know > how things were built... It will tell us if it was for e.g. an ARM or MIPS ELF file, but I'm not sure how we can tell the difference between an arm and an armv6 ELF. With armv6 there are a few changes in the userland/kernel interface, e.g. reading the thread local storage pointer is different such that an armv6 static binary would not run on an ARMv5 core as it uses newer instructions. Andrew From owner-freebsd-arch@FreeBSD.ORG Tue Jul 9 23:14:57 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 1E6E472F; Tue, 9 Jul 2013 23:14:57 +0000 (UTC) (envelope-from jordan.hubbard@gmail.com) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) by mx1.freebsd.org (Postfix) with ESMTP id E3E6E12FB; Tue, 9 Jul 2013 23:14:56 +0000 (UTC) Received: by mail-pa0-f50.google.com with SMTP id fb1so6066247pad.37 for ; Tue, 09 Jul 2013 16:14:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=fL6zDBfH3mn0Ww5EY/M/YFbMzCvb3pq4pMH5AoVuXKE=; b=hDMpJKJK9/2nRANV+yqLy5nYm/fH1e2spCI4Z9tTnYYj7N/+OmxdeeVuJCWVuxa5iG hBYDq69u8yW6DTEwwMLKBg126j29+vOv2tAKYhav/kcDnpX+FnvL1XaxJPkze3y+/s8u vnCGqNUEle3thEgD6GHq7/0ga4gQ+weBD2RaAJSq01SXqWrEzt0fqzPgmQ4fzboUt8fU jR3QWoUWc3jGjjyvIyvNnyzZslJfAdxHmf72NaJetIvuikFMXTz38LP44tKSjQx3FbXs fpQlyrJTDhtwASzjB0dYCf74gmYtj9gkLn1uTyGN2s7fp/mq14u1jiD8Uz4SeWDiV0yS wg6g== X-Received: by 10.68.131.168 with SMTP id on8mr28564965pbb.97.1373411696736; Tue, 09 Jul 2013 16:14:56 -0700 (PDT) Received: from [10.191.236.221] (81.sub-70-197-25.myvzw.com. [70.197.25.81]) by mx.google.com with ESMTPSA id yj2sm30391495pbb.40.2013.07.09.16.14.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Jul 2013 16:14:55 -0700 (PDT) References: <20130704215329.GG1402@garage.freebsd.pl> <20130708213351.GB1405@garage.freebsd.pl> <201307091039.26835.jhb@freebsd.org> Mime-Version: 1.0 (1.0) In-Reply-To: <201307091039.26835.jhb@freebsd.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPad Mail (10B329) From: Jordan Hubbard Subject: Re: General purpose library for name/value pairs. Date: Tue, 9 Jul 2013 16:14:52 -0700 To: John Baldwin 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: Tue, 09 Jul 2013 23:14:57 -0000 Yes, for anonymous shms this is certainly true. Hey, if the application pro= grammer *wants* to just pass a fd reference then there's certainly nothing p= reventing them from doing so in either case, I'm just suggesting that having= an explicit OOB type for shared memory (named or otherwise) can be a good t= hing too. - Jordan=20 Sent from my iPad On Jul 9, 2013, at 7:39, John Baldwin wrote: > I'll only speak to the GC point. For anonymous shm's (SHM_ANON), the segm= ent > is in fact GC'd on last close as there is no name to hold a reference to i= t. From owner-freebsd-arch@FreeBSD.ORG Wed Jul 10 00:40: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 30E79D83 for ; Wed, 10 Jul 2013 00:40:54 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qe0-x232.google.com (mail-qe0-x232.google.com [IPv6:2607:f8b0:400d:c02::232]) by mx1.freebsd.org (Postfix) with ESMTP id EC3BD1928 for ; Wed, 10 Jul 2013 00:40:53 +0000 (UTC) Received: by mail-qe0-f50.google.com with SMTP id f6so3364049qej.23 for ; Tue, 09 Jul 2013 17:40:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=FiC9BE4J5TJusV99s2j0KFsaWW5zZDRH1YufJ3E43VM=; b=K4ILKxSrXesgRih7MmCgRmqrfjUtCDV3Kva8t/Da1hGOkdECGJ1GYQOjayNC4fn4Ki tsVDp+0k44By4MvCGK+8UV5/KQi7i3s3FZR1P90N5ZKy7P1SOqJeDgOOnEyPYLSqo/Fh hMKA4j5dvVGdNPrGGtVdI2edfWUI4jWPi93zoKH6ZKu974/JM1jhOEwI3UUEmAvQhMB1 Tdk/xk9mZl8HVYmk8rxw29mBr3COB0tn2GMViZYflhem06Tu4XNhHOXYS8gy+QltCkkz jq0S69KdlhU53YB9Qr+gE1gODc2P3tn0s9yWzfEz6/243voCNcFtTAgKygapUu8D9pAH op9w== MIME-Version: 1.0 X-Received: by 10.224.13.19 with SMTP id z19mr25923482qaz.12.1373416853341; Tue, 09 Jul 2013 17:40:53 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.195.72 with HTTP; Tue, 9 Jul 2013 17:40:53 -0700 (PDT) In-Reply-To: <20130709234837.559e3769@bender.Home> References: <20130709090744.0e497e7e@bender.Home> <32F979BD-FB5C-4111-9586-4C5E7C6DFA71@bsdimp.com> <20130709234837.559e3769@bender.Home> Date: Tue, 9 Jul 2013 17:40:53 -0700 X-Google-Sender-Auth: yj7776td5rJO6v5EOJk5_L-lgw0 Message-ID: Subject: Re: Adding a MACHINE_ARCH note From: Adrian Chadd To: Andrew Turner Content-Type: text/plain; charset=ISO-8859-1 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, 10 Jul 2013 00:40:54 -0000 Someone pointed out there's dirty people running 32-bit binaries using the 64-bit intel/amd instruction set. Is this also able to represent that? -adrian On 9 July 2013 15:48, Andrew Turner wrote: > On Tue, 9 Jul 2013 08:19:46 -0600 > Warner Losh wrote: >> I thought that the ELF headers gave us all the data we needed to know >> how things were built... > > It will tell us if it was for e.g. an ARM or MIPS ELF file, but I'm not > sure how we can tell the difference between an arm and an armv6 ELF. > > With armv6 there are a few changes in the userland/kernel > interface, e.g. reading the thread local storage pointer is different > such that an armv6 static binary would not run on an ARMv5 core as it > uses newer instructions. > > Andrew > _______________________________________________ > 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 Wed Jul 10 00:42:01 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 C71A6E2F; Wed, 10 Jul 2013 00:42:01 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qa0-x22d.google.com (mail-qa0-x22d.google.com [IPv6:2607:f8b0:400d:c00::22d]) by mx1.freebsd.org (Postfix) with ESMTP id 7C3131930; Wed, 10 Jul 2013 00:42:01 +0000 (UTC) Received: by mail-qa0-f45.google.com with SMTP id ci6so6759986qab.11 for ; Tue, 09 Jul 2013 17:42:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=EHR7b1x+faBXPiHDaQwqZkOTs0rf5wH77ybSxF5qp7k=; b=IZEJp7aYyDUuF1bbqf7mxEJjMi6hf8HElQ1zK4nDwqRCkK+++M9UBrCzHQKRJbhBcJ GEvGUyfDjrTGFvJyNKV4F2TOEi6tcwrdR3kYKanNGbKU3DaXkInHr++eEnqTiWXShOgf Xf0dvPZqlRl84s4CnoCcplkRO5k54X8K6/56j7M+TeBhVbpGEWCPFPfFWMLeuAYo6zzq LztvFkuLbxRRWWmD+glKYcCOZcZZFw0HL88v8SaP22uIDMWQQkI5VUw8yrPazsFNdW1c cSI2T5ijhNNa+ykHckVZvzY2lZ1JGBFAPY2bijvU480J+sfdr5q318vKEWSYmLyzWH+W msEA== MIME-Version: 1.0 X-Received: by 10.49.107.201 with SMTP id he9mr23449099qeb.74.1373416921075; Tue, 09 Jul 2013 17:42:01 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.195.72 with HTTP; Tue, 9 Jul 2013 17:42:00 -0700 (PDT) In-Reply-To: References: <20130704215329.GG1402@garage.freebsd.pl> <20130708213351.GB1405@garage.freebsd.pl> <201307091039.26835.jhb@freebsd.org> Date: Tue, 9 Jul 2013 17:42:00 -0700 X-Google-Sender-Auth: 5nE76ZIPoQkUFiA4B9g-l0mIb9U Message-ID: Subject: Re: General purpose library for name/value pairs. From: Adrian Chadd To: Jordan Hubbard Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 00:42:01 -0000 On 9 July 2013 16:14, Jordan Hubbard wrote: > Yes, for anonymous shms this is certainly true. Hey, if the application = programmer *wants* to just pass a fd reference then there's certainly nothi= ng preventing them from doing so in either case, I'm just suggesting that h= aving an explicit OOB type for shared memory (named or otherwise) can be a = good thing too. You people are evil. I hope you stick to writing gui environments. -adrian ( :-) From owner-freebsd-arch@FreeBSD.ORG Wed Jul 10 00:54: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 9BF1B129 for ; Wed, 10 Jul 2013 00:54:03 +0000 (UTC) (envelope-from peter@wemm.org) Received: from mail-vc0-x231.google.com (mail-vc0-x231.google.com [IPv6:2607:f8b0:400c:c03::231]) by mx1.freebsd.org (Postfix) with ESMTP id 5D3F3199B for ; Wed, 10 Jul 2013 00:54:03 +0000 (UTC) Received: by mail-vc0-f177.google.com with SMTP id hv10so4782770vcb.8 for ; Tue, 09 Jul 2013 17:54:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MopiFGWEVkKzXhsf/Om8GGlUNvJ7/nMAd8kXg8Kg4ig=; b=rDRcIzu2Kja2GiulAioIzxxGHuO1SMwyJxR6WTuK+SzDOJs1TfuJc0sSB0Wl4ZK7xN MGSwQqZb8QY/WQ2FGLv1OIPGS4IFPEYGDXDdPCooWHsSPRlmDTpUFw8fhHJ9M149uisR 5f+bgxHpiDmLy0ZpJhrobLE75jmglu2wYyeMg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=MopiFGWEVkKzXhsf/Om8GGlUNvJ7/nMAd8kXg8Kg4ig=; b=VsVuLR9Dsu2fHzmj5rm0v4JQJUYdGhL6AQnFpB5x7JGw5fdt60FbmcZa6zY1e6d9w/ Tl7g9YtUp4xpA+56b155jd1igge7bbPbOZ5vXfWeEtMLz7sKwXx3F1F0T+PI14aw27b+ bwlH5GNHzCB4ShYC15v+QCW06FgLqt113JY6/zmGKY3fD5x+c2CL1EtvEtl5cKPioC5z 67NIYoaZf/LMMPlRIPV5YGEYY495S9erZ7bc8dgPgXIWXxOI3V6MSWwiPu641LYML89E r9OnaO8aLONQmUUL4yzR0YHALLoWv3DIAhZC8ymIWaApEcOLF3i0BsJ+l1l+YfP6+RWa 6PDA== MIME-Version: 1.0 X-Received: by 10.220.47.131 with SMTP id n3mr17962174vcf.7.1373417642756; Tue, 09 Jul 2013 17:54:02 -0700 (PDT) Received: by 10.221.37.198 with HTTP; Tue, 9 Jul 2013 17:54:02 -0700 (PDT) In-Reply-To: References: <20130709090744.0e497e7e@bender.Home> <32F979BD-FB5C-4111-9586-4C5E7C6DFA71@bsdimp.com> <20130709234837.559e3769@bender.Home> Date: Tue, 9 Jul 2013 17:54:02 -0700 Message-ID: Subject: Re: Adding a MACHINE_ARCH note From: Peter Wemm To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnMMQJ25/KkB4bfiSNOE8MQT9bmhPgG3NmqK1EN++Bmyc8b5kfPKKjzMI1SGsfQLg97gntm Cc: Andrew Turner , 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, 10 Jul 2013 00:54:03 -0000 On Tue, Jul 9, 2013 at 5:40 PM, Adrian Chadd wrote: > Someone pointed out there's dirty people running 32-bit binaries using > the 64-bit intel/amd instruction set. > > Is this also able to represent that? That would be "X32", so there's 3 x86 ABI variants: i386 - 32 bit amd64 - 32 bit amd64 - 64 bit Incidentally, pkgng has a issues with this. For some reason it lumps both i386 and amd64 into a single pseudo-arch called "x86" with a 32 and 64 bit variant. It doesn't leave room for distinguishing the two incompatible 32 bit architectures. "x32" is where the compiler generates code where "long" and "pointer" are 32 bit, but the instruction set is otherwise amd64 and has all 16 general purpose registers available. "long long" is a 64 bit register instead of a pair of 32 bit registers like on i386. > -adrian > > On 9 July 2013 15:48, Andrew Turner wrote: >> On Tue, 9 Jul 2013 08:19:46 -0600 >> Warner Losh wrote: >>> I thought that the ELF headers gave us all the data we needed to know >>> how things were built... >> >> It will tell us if it was for e.g. an ARM or MIPS ELF file, but I'm not >> sure how we can tell the difference between an arm and an armv6 ELF. >> >> With armv6 there are a few changes in the userland/kernel >> interface, e.g. reading the thread local storage pointer is different >> such that an armv6 static binary would not run on an ARMv5 core as it >> uses newer instructions. >> >> Andrew >> _______________________________________________ >> 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" > _______________________________________________ > 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" -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV UTF-8: So you can \342\200\231 .. for when a ' just won't do ZFS must be the bacon of file systems. "everything's better with ZFS" From owner-freebsd-arch@FreeBSD.ORG Wed Jul 10 00:56: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 6684C1EA; Wed, 10 Jul 2013 00:56:07 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qa0-x22c.google.com (mail-qa0-x22c.google.com [IPv6:2607:f8b0:400d:c00::22c]) by mx1.freebsd.org (Postfix) with ESMTP id 1B38719AD; Wed, 10 Jul 2013 00:56:07 +0000 (UTC) Received: by mail-qa0-f44.google.com with SMTP id o13so6765694qaj.10 for ; Tue, 09 Jul 2013 17:56:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=4isJjG86kySH/Wtk/dSUUO2U976+7MLA4RBNQ7vuElA=; b=Ubqvl1a/aFrZAOqyxNXwiHxRlI+ftfIgrIuqb4yQ9V2+C6NI2sqCqdT9svLXnOIuT1 7/2rm2y6ht/kqbg73dVZDX6rlEBcB80FLcRpOAc0ZYPHDyy63nBnj70SajiXKuj5IPuF IO4nLM36pZVY9JTehO4I5/KRT63TsDSBUsQSKJYZfHZqHG+vCoKRdPUlcehYzxs9TY3B fKh38MTEFTtourGjYADXFSY5JuOzEyYWbM//5KT5wme528HibcKfHZHVbh6YLffEmEP+ OMMjm1I2KcpSsxm3OirxODwaTKu9QXWdB8IvLHXeCDPmt339nUyCDZ5whtjhqB6pZ4zs cUrQ== MIME-Version: 1.0 X-Received: by 10.224.127.73 with SMTP id f9mr25655142qas.4.1373417766660; Tue, 09 Jul 2013 17:56:06 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.195.72 with HTTP; Tue, 9 Jul 2013 17:56:06 -0700 (PDT) In-Reply-To: References: <20130709090744.0e497e7e@bender.Home> <32F979BD-FB5C-4111-9586-4C5E7C6DFA71@bsdimp.com> <20130709234837.559e3769@bender.Home> Date: Tue, 9 Jul 2013 17:56:06 -0700 X-Google-Sender-Auth: PVa3b4nrdCgzj83A02RjUCsmfyQ Message-ID: Subject: Re: Adding a MACHINE_ARCH note From: Adrian Chadd To: Peter Wemm Content-Type: text/plain; charset=ISO-8859-1 Cc: Baptiste Daroussin , Andrew Turner , 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, 10 Jul 2013 00:56:07 -0000 ... boy I'd like to see this particular x86 hiccup fixed before this stuff is mainstream. adrian On 9 July 2013 17:54, Peter Wemm wrote: > On Tue, Jul 9, 2013 at 5:40 PM, Adrian Chadd wrote: >> Someone pointed out there's dirty people running 32-bit binaries using >> the 64-bit intel/amd instruction set. >> >> Is this also able to represent that? > > That would be "X32", so there's 3 x86 ABI variants: > i386 - 32 bit > amd64 - 32 bit > amd64 - 64 bit > > Incidentally, pkgng has a issues with this. For some reason it lumps > both i386 and amd64 into a single pseudo-arch called "x86" with a 32 > and 64 bit variant. It doesn't leave room for distinguishing the two > incompatible 32 bit architectures. > > "x32" is where the compiler generates code where "long" and "pointer" > are 32 bit, but the instruction set is otherwise amd64 and has all 16 > general purpose registers available. "long long" is a 64 bit > register instead of a pair of 32 bit registers like on i386. > >> -adrian >> >> On 9 July 2013 15:48, Andrew Turner wrote: >>> On Tue, 9 Jul 2013 08:19:46 -0600 >>> Warner Losh wrote: >>>> I thought that the ELF headers gave us all the data we needed to know >>>> how things were built... >>> >>> It will tell us if it was for e.g. an ARM or MIPS ELF file, but I'm not >>> sure how we can tell the difference between an arm and an armv6 ELF. >>> >>> With armv6 there are a few changes in the userland/kernel >>> interface, e.g. reading the thread local storage pointer is different >>> such that an armv6 static binary would not run on an ARMv5 core as it >>> uses newer instructions. >>> >>> Andrew >>> _______________________________________________ >>> 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" >> _______________________________________________ >> 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" > > > > -- > Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV > UTF-8: So you can \342\200\231 .. for when a ' just won't do > ZFS must be the bacon of file systems. "everything's better with ZFS" From owner-freebsd-arch@FreeBSD.ORG Wed Jul 10 01:08:31 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 B6616395 for ; Wed, 10 Jul 2013 01:08:31 +0000 (UTC) (envelope-from peter@wemm.org) Received: from mail-vb0-x22d.google.com (mail-vb0-x22d.google.com [IPv6:2607:f8b0:400c:c02::22d]) by mx1.freebsd.org (Postfix) with ESMTP id 759FF19FE for ; Wed, 10 Jul 2013 01:08:31 +0000 (UTC) Received: by mail-vb0-f45.google.com with SMTP id p14so4951568vbm.18 for ; Tue, 09 Jul 2013 18:08:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GlemqQyokDRHNPSJ9NgSylPMcymSDZfREKE2GKeNA9k=; b=mGk6Sux4bXDXHye7i21AqxoujNTWUpgDPcewE+3Oyc4ofXaFfKxb213RFUen32XzMW mHqTnbi7senQy4WtnyAXDHDnzMlQnCqxqNxVHeJ/hIyPLU11wn91KxrwrVHc5agzitQY KPxBMALnZxnICOGQMcxnnAxNC3fXBDcZy8JVw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=GlemqQyokDRHNPSJ9NgSylPMcymSDZfREKE2GKeNA9k=; b=d3pzfaxFaPQvNVHQPUkUB1eIoCBK3wbhmHZCPLMSrra++OydAGY4ckW9JsRQV619vP h0kzhJt7W76w4YTg6zOegkyyrSajZhATArumlvb6aZxoTExZDDnU1H8HB7GK3eGT0fOQ qcBXIYL7IrrQ3ko+HhayEjHXHTEVzlf2KxFEx+XhdTgUSK4RgQhLYDUGnXTOYWmMbMl6 r/OupNhvdSW30lmHKTZzlZ32u9jTZho7c9iTnVXb7hp5zaplE6leqgT9SGZuv94o/chk gdl2kOLr9083KoqvVjUjvmOxRJZL6cjtDYLdXU2Bvqr7y3B6qeIu75m5k7RDI2FTqxq2 ZjhA== MIME-Version: 1.0 X-Received: by 10.52.72.49 with SMTP id a17mr5980402vdv.15.1373418510980; Tue, 09 Jul 2013 18:08:30 -0700 (PDT) Received: by 10.221.37.198 with HTTP; Tue, 9 Jul 2013 18:08:30 -0700 (PDT) In-Reply-To: References: <20130709090744.0e497e7e@bender.Home> <32F979BD-FB5C-4111-9586-4C5E7C6DFA71@bsdimp.com> <20130709234837.559e3769@bender.Home> Date: Tue, 9 Jul 2013 18:08:30 -0700 Message-ID: Subject: Re: Adding a MACHINE_ARCH note From: Peter Wemm To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnLdU1v6km2kl0hynArUXjFKRgqqKeSFONq9eNL5LoJC2iVsPEgJjp+AyBFNiEGRh/waRIs Cc: Baptiste Daroussin , Andrew Turner , 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, 10 Jul 2013 01:08:31 -0000 On Tue, Jul 9, 2013 at 5:56 PM, Adrian Chadd wrote: > ... boy I'd like to see this particular x86 hiccup fixed before this > stuff is mainstream. I'm not entirely sure how much support there is behind "x32". I don't know if its much more than an academic curiosity or if there's real demand for it. gcc-4.8 and clang have it, or have patches for it. https://sites.google.com/site/x32abi/ http://www.phoronix.com/scan.php?page=news_item&px=MTExNDE > adrian > > On 9 July 2013 17:54, Peter Wemm wrote: >> On Tue, Jul 9, 2013 at 5:40 PM, Adrian Chadd wrote: >>> Someone pointed out there's dirty people running 32-bit binaries using >>> the 64-bit intel/amd instruction set. >>> >>> Is this also able to represent that? >> >> That would be "X32", so there's 3 x86 ABI variants: >> i386 - 32 bit >> amd64 - 32 bit >> amd64 - 64 bit >> >> Incidentally, pkgng has a issues with this. For some reason it lumps >> both i386 and amd64 into a single pseudo-arch called "x86" with a 32 >> and 64 bit variant. It doesn't leave room for distinguishing the two >> incompatible 32 bit architectures. >> >> "x32" is where the compiler generates code where "long" and "pointer" >> are 32 bit, but the instruction set is otherwise amd64 and has all 16 >> general purpose registers available. "long long" is a 64 bit >> register instead of a pair of 32 bit registers like on i386. >> >>> -adrian >>> >>> On 9 July 2013 15:48, Andrew Turner wrote: >>>> On Tue, 9 Jul 2013 08:19:46 -0600 >>>> Warner Losh wrote: >>>>> I thought that the ELF headers gave us all the data we needed to know >>>>> how things were built... >>>> >>>> It will tell us if it was for e.g. an ARM or MIPS ELF file, but I'm not >>>> sure how we can tell the difference between an arm and an armv6 ELF. >>>> >>>> With armv6 there are a few changes in the userland/kernel >>>> interface, e.g. reading the thread local storage pointer is different >>>> such that an armv6 static binary would not run on an ARMv5 core as it >>>> uses newer instructions. >>>> >>>> Andrew >>>> _______________________________________________ >>>> 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" >>> _______________________________________________ >>> 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" >> >> >> >> -- >> Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV >> UTF-8: So you can \342\200\231 .. for when a ' just won't do >> ZFS must be the bacon of file systems. "everything's better with ZFS" -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV UTF-8: So you can \342\200\231 .. for when a ' just won't do ZFS must be the bacon of file systems. "everything's better with ZFS" From owner-freebsd-arch@FreeBSD.ORG Wed Jul 10 01:52: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 10E24503; Wed, 10 Jul 2013 01:52:09 +0000 (UTC) (envelope-from jordan.hubbard@gmail.com) Received: from mail-pb0-x231.google.com (mail-pb0-x231.google.com [IPv6:2607:f8b0:400e:c01::231]) by mx1.freebsd.org (Postfix) with ESMTP id D4E901B9D; Wed, 10 Jul 2013 01:52:08 +0000 (UTC) Received: by mail-pb0-f49.google.com with SMTP id jt11so6085401pbb.8 for ; Tue, 09 Jul 2013 18:52:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=eXtaImCOcORvKNEgCV3u292/refQfz6+8GAH1jtCa0g=; b=hBfX+h0AOW0DWjkdjK6HflIeuNzoAAwy7Ai4pl1IBcR/AGl96bQ+nbSR4Wls90RRHR bHFZlfsGzyY6YlDMzMI5EI/30E9WkkdglvPRvB0eM9PVs3dnaINbOSPzBs+YsRUTzDTa MpHwyaOOx88tudjoMt3FYxgIZ5dfQx0DPFBAipez2ZLK9J2VRjlizBaLwopatPVtCXJX ZG9BNuPqwde10Yh4jzWmkBSf2jfdN8cavY9m38MZV3QhvZ4gOISb0wt5vph4dtBHt4mR LiyoHoszqUWAck674NspjEdGqzr0qvl3Dihdi2F2ezhQyhOrBVfgyhZ0KknnM5wW+C5X PQDQ== X-Received: by 10.66.190.101 with SMTP id gp5mr30268430pac.19.1373421128732; Tue, 09 Jul 2013 18:52:08 -0700 (PDT) Received: from [10.20.30.11] (75-101-82-48.static.sonic.net. [75.101.82.48]) by mx.google.com with ESMTPSA id kc8sm30956666pbc.18.2013.07.09.18.52.07 for (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Jul 2013 18:52:08 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1784.1\)) Subject: Re: General purpose library for name/value pairs. From: Jordan Hubbard In-Reply-To: Date: Tue, 9 Jul 2013 18:52:07 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <82E12BF2-2834-444C-BA24-47DCBF7BD71B@gmail.com> References: <20130704215329.GG1402@garage.freebsd.pl> <20130708213351.GB1405@garage.freebsd.pl> <201307091039.26835.jhb@freebsd.org> To: Adrian Chadd X-Mailer: Apple Mail (2.1784.1) 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, 10 Jul 2013 01:52:09 -0000 On Jul 9, 2013, at 5:42 PM, Adrian Chadd wrote: > You people are evil. I hope you stick to writing gui environments. And that, in one sentence, is why FreeBSD STILL has no generalized = preference API. Just a bucket of freeform and otherwise disassociated = bits in /etc. ;-) - Jordan From owner-freebsd-arch@FreeBSD.ORG Wed Jul 10 03:03: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 C827C238 for ; Wed, 10 Jul 2013 03:03:00 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-f177.google.com (mail-ie0-f177.google.com [209.85.223.177]) by mx1.freebsd.org (Postfix) with ESMTP id 9BD6E1ED2 for ; Wed, 10 Jul 2013 03:03:00 +0000 (UTC) Received: by mail-ie0-f177.google.com with SMTP id aq17so14240170iec.36 for ; Tue, 09 Jul 2013 20:02:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=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=9Al2KcZqeTjR+/gO3Xf+XmP5lNIE29l/vo8FcpR38Rc=; b=OciC+8Sr/iYoGMo5ZU7C/BBFjR9B2+N1qCYpOr6zBS2hr4ilmmIjwU2zB10j2wBHTo RQemIuk+PEHjvUx3fcubg0eqIN+Nt4s0dkGPQoFSRnJ+GNwbfoUZoKnUBr+/pqBQwTNM 2sjmYn9StiDjuiVnJNDiBA+NTadl46/F+r0K2UKFRW2iHAT0XvE8xndGxQRW/83U8xN1 gvxP0XR3BBm/2+VjXC7bBdpyuOXKalTH0YthI/zWYnFA4vogaPjAp1ADfQnf7R2gB8QJ ZySItXoFmSg46wV/LmHO8Zl0NOcUGhvxpzc2zy1L2lsAe1kppn0URmrR/Ucc80uwcNA3 iwZg== X-Received: by 10.50.67.111 with SMTP id m15mr10914343igt.54.1373425374590; Tue, 09 Jul 2013 20:02:54 -0700 (PDT) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id z15sm36695467igp.0.2013.07.09.20.02.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Jul 2013 20:02:53 -0700 (PDT) Sender: Warner Losh Subject: Re: Adding a MACHINE_ARCH note Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20130709234837.559e3769@bender.Home> Date: Tue, 9 Jul 2013 21:02:51 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <95B55330-1AC8-467C-942C-50795F168E49@bsdimp.com> References: <20130709090744.0e497e7e@bender.Home> <32F979BD-FB5C-4111-9586-4C5E7C6DFA71@bsdimp.com> <20130709234837.559e3769@bender.Home> To: Andrew Turner X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQlUeI4meifHhnN4ncksgy3phFQ8DPwyXlQ/MR59rrxo3OFJkP6dv2xdyO77y1dbAEJuC5jn 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, 10 Jul 2013 03:03:00 -0000 On Jul 9, 2013, at 4:48 PM, Andrew Turner wrote: > On Tue, 9 Jul 2013 08:19:46 -0600 > Warner Losh wrote: >> I thought that the ELF headers gave us all the data we needed to know >> how things were built... >=20 > It will tell us if it was for e.g. an ARM or MIPS ELF file, but I'm = not > sure how we can tell the difference between an arm and an armv6 ELF. >=20 > With armv6 there are a few changes in the userland/kernel > interface, e.g. reading the thread local storage pointer is different > such that an armv6 static binary would not run on an ARMv5 core as it > uses newer instructions. On MIPS I know all that is encoded in the ELF headers for sure, so I = went looking for ARM. OK. Found the ARM elf spec. = http://infocenter.arm.com/help/topic/com.arm.doc.dui0101a/DUI0101A_Elf.pdf= which is updated by = http://infocenter.arm.com/help/topic/com.arm.doc.ihi0044e/IHI0044E_aaelf.p= df For big endian vs little endian: ei_data is set to ELFDATA2LSB or = ELFDATA2MSB. EABI is denoted by setting EI_OSABI to ELFOSABI_ARM_AEABI. e_flags will have some info as well: EF_ARM_ABIMASK 0xFF000000 (value of 5 for EABI for armv6) EF_ARM_BE8 0x00800000 - The ELF file contains BE-8 code, suitable for = execution on an ARM=20 Architecture v6 processor EF_ARM_ABI_FLOAT_HARD 0x00000400 - Set in executable file headers = (e_type =3D ET_EXEC or ET_DYN) to note that=20 the executable file was built to conform to the hardware floating-point=20= procedure-call standard. Compatible with legacy (pre version 5) gcc use as EF_ARM_VFP_FLOAT. EF_ARM_ABI_FLOAT_SOFT 0x00000200 - Set in executable file headers = (e_type =3D ET_EXEC or ET_DYN) to note=20 explicitly that the executable file was built to conform to the software=20= floating-point procedure-call standard (the base standard). If both=20 EF_ARM_ABI_FLOAT_XXXX bits are clear, conformance to the base=20 procedure-call standard is implied. Compatible with legacy (pre version 5) gcc use as EF_ARM_SOFT_FLOAT What else is needed? Warner From owner-freebsd-arch@FreeBSD.ORG Wed Jul 10 03:04:21 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 9446B416 for ; Wed, 10 Jul 2013 03:04:21 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-f170.google.com (mail-ie0-f170.google.com [209.85.223.170]) by mx1.freebsd.org (Postfix) with ESMTP id 662881F0E for ; Wed, 10 Jul 2013 03:04:21 +0000 (UTC) Received: by mail-ie0-f170.google.com with SMTP id e11so14637273iej.29 for ; Tue, 09 Jul 2013 20:04:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=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=73QARi8s0s7HjUScjTcK9b9GWxcleOlTTr1uQAvFJao=; b=AlQdH06YN5E1jFjjNnWkYTverj4zIokFZha9pWj5p1bXa2AvbGprjHUfidKvr8dlTo HJtwHraeEn6vthd04zZuBXbyOw4bfrlIL0TPstWj0s4KdE0OoHnvEiz5EB5cVRNnkrA8 aIcXgRtpjVgt0G0lSI/0o7U/FUr/H33/kmJDjlhjKgHxv6UXMilDuVW0Extn2uJe3UCW LWAqXAIPMnbB8o09CN+v0fMapDX/d6Aq7BXZcDxlnxQNBAP2wcbw1v2dQGTRMBUcxClc X5VLyQDqW+Z9OWtlcBkkJVfl+ivJoc7oCgkpaj74kIDoTxVvVEDCgLNZaoT2JyIdL79y ZMXg== X-Received: by 10.42.70.194 with SMTP id g2mr9344602icj.83.1373425455748; Tue, 09 Jul 2013 20:04:15 -0700 (PDT) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id d14sm7876863igz.6.2013.07.09.20.04.14 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Jul 2013 20:04:14 -0700 (PDT) Sender: Warner Losh Subject: Re: Adding a MACHINE_ARCH note Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Tue, 9 Jul 2013 21:04:12 -0600 Content-Transfer-Encoding: 7bit Message-Id: <5F95D699-78E2-493C-ACB7-D26D70FE3D49@bsdimp.com> References: <20130709090744.0e497e7e@bender.Home> <32F979BD-FB5C-4111-9586-4C5E7C6DFA71@bsdimp.com> <20130709234837.559e3769@bender.Home> To: Adrian Chadd X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQlC5QIxuO5aEUBg5GQ4kjkJh4XeZ+Vy6Mbu6PZ+jXP9jLBL8vSZPlDQsAdQcPooWKHmIE/u Cc: Andrew Turner , 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, 10 Jul 2013 03:04:21 -0000 On Jul 9, 2013, at 6:40 PM, Adrian Chadd wrote: > Someone pointed out there's dirty people running 32-bit binaries using > the 64-bit intel/amd instruction set. > > Is this also able to represent that? The elf headers represent that. Warner > > -adrian > > On 9 July 2013 15:48, Andrew Turner wrote: >> On Tue, 9 Jul 2013 08:19:46 -0600 >> Warner Losh wrote: >>> I thought that the ELF headers gave us all the data we needed to know >>> how things were built... >> >> It will tell us if it was for e.g. an ARM or MIPS ELF file, but I'm not >> sure how we can tell the difference between an arm and an armv6 ELF. >> >> With armv6 there are a few changes in the userland/kernel >> interface, e.g. reading the thread local storage pointer is different >> such that an armv6 static binary would not run on an ARMv5 core as it >> uses newer instructions. >> >> Andrew >> _______________________________________________ >> 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 Wed Jul 10 03:05: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 2E02A4C2 for ; Wed, 10 Jul 2013 03:05:19 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) by mx1.freebsd.org (Postfix) with ESMTP id F24711F18 for ; Wed, 10 Jul 2013 03:05:18 +0000 (UTC) Received: by mail-ie0-f182.google.com with SMTP id s9so14483488iec.27 for ; Tue, 09 Jul 2013 20:05:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=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=f5b0yn7WgWvGInIEck2B2WORvk5PIrfiJ8gFYK66h2w=; b=cpS2Zji+KaoZUiSK8//TFiE57/FD4wARkZpFrsQaQm9Cw6C3yNQMiwUFtdgoOyc9kE iPEdLcAWigeMOjBDViypj8HKwr+MMQFOo/8kmOglZVOyriDqnFNGSykXQKj2aGBMn+YN hKA0yh8oplgQcZ3U3DdjoSYMvHpreZdyg506FfgOIF/4+hhNB3pbDwqjxYZwAgeydD7x SCVhIztNGgxHzldIuK5TGYuXBWCx7a3oq87tNuYXTe/jTLZj40vXeVyEZ0yIde7Hi5ql YbMcmc87gwAKyUO1387OPcWH9GtwUZiDaEWlYj6jMmXRX9fL90KEBxV3RRqg3IdZVcFn Nqxw== X-Received: by 10.50.128.166 with SMTP id np6mr2137194igb.55.1373425518516; Tue, 09 Jul 2013 20:05:18 -0700 (PDT) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id y2sm5063924igl.10.2013.07.09.20.05.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Jul 2013 20:05:17 -0700 (PDT) Sender: Warner Losh Subject: Re: Adding a MACHINE_ARCH note Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Tue, 9 Jul 2013 21:05:15 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <1983B14D-774E-471E-883F-A25010B43810@bsdimp.com> References: <20130709090744.0e497e7e@bender.Home> <32F979BD-FB5C-4111-9586-4C5E7C6DFA71@bsdimp.com> <20130709234837.559e3769@bender.Home> To: Peter Wemm X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQnmhmgq4C3E5SPLRblNEUJP1oNnqfvXKYjHsI6h1W8OYlWbSDQDqvRkmStW/n8QSqki11T9 Cc: Adrian Chadd , Andrew Turner , 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, 10 Jul 2013 03:05:19 -0000 On Jul 9, 2013, at 6:54 PM, Peter Wemm wrote: > On Tue, Jul 9, 2013 at 5:40 PM, Adrian Chadd = wrote: >> Someone pointed out there's dirty people running 32-bit binaries = using >> the 64-bit intel/amd instruction set. >>=20 >> Is this also able to represent that? >=20 > That would be "X32", so there's 3 x86 ABI variants: > i386 - 32 bit > amd64 - 32 bit > amd64 - 64 bit >=20 > Incidentally, pkgng has a issues with this. For some reason it lumps > both i386 and amd64 into a single pseudo-arch called "x86" with a 32 > and 64 bit variant. It doesn't leave room for distinguishing the two > incompatible 32 bit architectures. >=20 > "x32" is where the compiler generates code where "long" and "pointer" > are 32 bit, but the instruction set is otherwise amd64 and has all 16 > general purpose registers available. "long long" is a 64 bit > register instead of a pair of 32 bit registers like on i386. I got Babt to agree to move pkgng to using uname -p, which is completely = sufficient on FreeBSD for all known architectures. He's in transition = for this now. Warner >=20 >> -adrian >>=20 >> On 9 July 2013 15:48, Andrew Turner wrote: >>> On Tue, 9 Jul 2013 08:19:46 -0600 >>> Warner Losh wrote: >>>> I thought that the ELF headers gave us all the data we needed to = know >>>> how things were built... >>>=20 >>> It will tell us if it was for e.g. an ARM or MIPS ELF file, but I'm = not >>> sure how we can tell the difference between an arm and an armv6 ELF. >>>=20 >>> With armv6 there are a few changes in the userland/kernel >>> interface, e.g. reading the thread local storage pointer is = different >>> such that an armv6 static binary would not run on an ARMv5 core as = it >>> uses newer instructions. >>>=20 >>> Andrew >>> _______________________________________________ >>> 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" >> _______________________________________________ >> 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" >=20 >=20 >=20 > --=20 > Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; = KI6FJV > UTF-8: So you can \342\200\231 .. for when a ' just won't do > ZFS must be the bacon of file systems. "everything's better = with ZFS" > _______________________________________________ > 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 Wed Jul 10 03:06: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 BD624594 for ; Wed, 10 Jul 2013 03:06:34 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-f173.google.com (mail-ie0-f173.google.com [209.85.223.173]) by mx1.freebsd.org (Postfix) with ESMTP id 8E3B41F39 for ; Wed, 10 Jul 2013 03:06:34 +0000 (UTC) Received: by mail-ie0-f173.google.com with SMTP id k13so14463280iea.32 for ; Tue, 09 Jul 2013 20:06:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=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=7Q77SLmr/+dHJZsKgsj+VMjvNnfnffEn7JXdIVVvoAY=; b=ArmX/oWlttqzjPYHSId+Y5Clm9WhB62QIjeppe+rDuSYOCe4MQDgAHxlTQJJWlGZ+l nu1yi2iU1k6cLnY5igeIqnXw+9cohccD73DO8LszYllfAQHmmItlPvRLbFz2aIvZr/TZ l2b+QH4yRloLg02emYyQtGFpfFYMFesBmkpKbejgjDd2mypK9U4UOJraSgVeX+XuHXF+ EKRayVKKXL2YsM2uUeCKN6f4Zglvn+Ud0Fi1E7/DfB9kg5/5J2j+pjz+6nVzIL+sAfnk 5pbTwwNyts5xRwiQdqyklq67G9rPrXUf3ltQdtcLuyKu5kGUOiDDoUzTJ6OSLVrwPlKc rHag== X-Received: by 10.42.74.72 with SMTP id v8mr9481877icj.31.1373425588508; Tue, 09 Jul 2013 20:06:28 -0700 (PDT) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id y9sm34618273iga.9.2013.07.09.20.06.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Jul 2013 20:06:27 -0700 (PDT) Sender: Warner Losh Subject: Re: General purpose library for name/value pairs. Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <82E12BF2-2834-444C-BA24-47DCBF7BD71B@gmail.com> Date: Tue, 9 Jul 2013 21:06:25 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <53FCD258-D3EE-49E7-838D-161E28DC8E09@bsdimp.com> References: <20130704215329.GG1402@garage.freebsd.pl> <20130708213351.GB1405@garage.freebsd.pl> <201307091039.26835.jhb@freebsd.org> <82E12BF2-2834-444C-BA24-47DCBF7BD71B@gmail.com> To: Jordan Hubbard X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQnfJ6+3bd9ieNDD7nUuRfnPLCVk98K17uQVtnlLiRDB8n/wghVeCgofzICOpCH8CE0F8thn Cc: Adrian Chadd , 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, 10 Jul 2013 03:06:34 -0000 On Jul 9, 2013, at 7:52 PM, Jordan Hubbard wrote: >=20 > On Jul 9, 2013, at 5:42 PM, Adrian Chadd wrote: >=20 >> You people are evil. I hope you stick to writing gui environments. >=20 > And that, in one sentence, is why FreeBSD STILL has no generalized = preference API. Just a bucket of freeform and otherwise disassociated = bits in /etc. ;-) You don't have to suck and/or want a GUI environment to want a unified = preference API. Warner From owner-freebsd-arch@FreeBSD.ORG Wed Jul 10 03:07:32 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 8BEB464E for ; Wed, 10 Jul 2013 03:07:32 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-f181.google.com (mail-ie0-f181.google.com [209.85.223.181]) by mx1.freebsd.org (Postfix) with ESMTP id 5AA151F4C for ; Wed, 10 Jul 2013 03:07:32 +0000 (UTC) Received: by mail-ie0-f181.google.com with SMTP id x12so13563714ief.26 for ; Tue, 09 Jul 2013 20:07:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=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=OQ9IKJ291o5pzQRoh/NmOeIfQ2uus92flWd/vnwXpkg=; b=Xm+LtF6K6PNC8dc6sy1peqYHdww5fLJRe+wfPab7Kbw32JUgQ4wRnz6fRRFZA+YSrK JVwYh5ODCMuyXxMCk9LKjiY+vCWuGXQ0MNVjek9L61HeUxq9PsqRPB57qwXMjn1ziR15 Z6erhb+jEYxY1Dz0g9GZilTH+MlVaKLFKyq20tTzT1GkHeb1OYnfmFCLP3Jhm+UJwPI0 pVkQ4EZ5VaR5O5wUXK9NQT/EpFHPPVMHQr9oULUfLZs+peMbM6IEGJl+fgGq8hKO/1pB aEdfrHmzBeHSa7d5lFSAlvbVOyYb/9mUIAph/2OC0fUkhz3NjvKIhONHsPWgto5ykrLt E5Uw== X-Received: by 10.43.14.74 with SMTP id pp10mr503229icb.87.1373425646747; Tue, 09 Jul 2013 20:07:26 -0700 (PDT) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id y9sm34618273iga.9.2013.07.09.20.07.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Jul 2013 20:07:25 -0700 (PDT) Sender: Warner Losh Subject: Re: Adding a MACHINE_ARCH note Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Tue, 9 Jul 2013 21:07:24 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <4B3C4D68-EF16-4B49-B8E7-FFDEAA751005@bsdimp.com> References: <20130709090744.0e497e7e@bender.Home> <32F979BD-FB5C-4111-9586-4C5E7C6DFA71@bsdimp.com> <20130709234837.559e3769@bender.Home> To: Peter Wemm X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQn32KOEHV4oOV64Ec+LZo0d3ZmxaBzvOROTU2cSHqUbLZ17OPJzuj4FtIkbQoN2E42gyPMf Cc: Adrian Chadd , freebsd-arch@freebsd.org, Baptiste Daroussin , Andrew Turner 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, 10 Jul 2013 03:07:32 -0000 On Jul 9, 2013, at 7:08 PM, Peter Wemm wrote: > On Tue, Jul 9, 2013 at 5:56 PM, Adrian Chadd = wrote: >> ... boy I'd like to see this particular x86 hiccup fixed before this >> stuff is mainstream. >=20 > I'm not entirely sure how much support there is behind "x32". I don't > know if its much more than an academic curiosity or if there's real > demand for it. gcc-4.8 and clang have it, or have patches for it. >=20 > https://sites.google.com/site/x32abi/ >=20 > http://www.phoronix.com/scan.php?page=3Dnews_item&px=3DMTExNDE If FreeBSD ever does support x32, we'd do what we do on MIPS for the = odd-ball n32 where we have mipsn32 as the uname -p. Warner >=20 >> adrian >>=20 >> On 9 July 2013 17:54, Peter Wemm wrote: >>> On Tue, Jul 9, 2013 at 5:40 PM, Adrian Chadd = wrote: >>>> Someone pointed out there's dirty people running 32-bit binaries = using >>>> the 64-bit intel/amd instruction set. >>>>=20 >>>> Is this also able to represent that? >>>=20 >>> That would be "X32", so there's 3 x86 ABI variants: >>> i386 - 32 bit >>> amd64 - 32 bit >>> amd64 - 64 bit >>>=20 >>> Incidentally, pkgng has a issues with this. For some reason it = lumps >>> both i386 and amd64 into a single pseudo-arch called "x86" with a 32 >>> and 64 bit variant. It doesn't leave room for distinguishing the = two >>> incompatible 32 bit architectures. >>>=20 >>> "x32" is where the compiler generates code where "long" and = "pointer" >>> are 32 bit, but the instruction set is otherwise amd64 and has all = 16 >>> general purpose registers available. "long long" is a 64 bit >>> register instead of a pair of 32 bit registers like on i386. >>>=20 >>>> -adrian >>>>=20 >>>> On 9 July 2013 15:48, Andrew Turner wrote: >>>>> On Tue, 9 Jul 2013 08:19:46 -0600 >>>>> Warner Losh wrote: >>>>>> I thought that the ELF headers gave us all the data we needed to = know >>>>>> how things were built... >>>>>=20 >>>>> It will tell us if it was for e.g. an ARM or MIPS ELF file, but = I'm not >>>>> sure how we can tell the difference between an arm and an armv6 = ELF. >>>>>=20 >>>>> With armv6 there are a few changes in the userland/kernel >>>>> interface, e.g. reading the thread local storage pointer is = different >>>>> such that an armv6 static binary would not run on an ARMv5 core as = it >>>>> uses newer instructions. >>>>>=20 >>>>> Andrew >>>>> _______________________________________________ >>>>> 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" >>>> _______________________________________________ >>>> 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" >>>=20 >>>=20 >>>=20 >>> -- >>> Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; = KI6FJV >>> UTF-8: So you can \342\200\231 .. for when a ' just won't do >>> ZFS must be the bacon of file systems. "everything's = better with ZFS" >=20 >=20 >=20 > --=20 > Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; = KI6FJV > UTF-8: So you can \342\200\231 .. for when a ' just won't do > ZFS must be the bacon of file systems. "everything's better = with ZFS" > _______________________________________________ > 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 Wed Jul 10 03:46: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 E175771B for ; Wed, 10 Jul 2013 03:46:04 +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 8188610B9 for ; Wed, 10 Jul 2013 03:46:04 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r6A3jtdR011866; Wed, 10 Jul 2013 06:45:55 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r6A3jtdR011866 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r6A3jtOj011865; Wed, 10 Jul 2013 06:45:55 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 10 Jul 2013 06:45:55 +0300 From: Konstantin Belousov To: Andrew Turner Subject: Re: Adding a MACHINE_ARCH note Message-ID: <20130710034554.GW91021@kib.kiev.ua> References: <20130709090744.0e497e7e@bender.Home> <32F979BD-FB5C-4111-9586-4C5E7C6DFA71@bsdimp.com> <20130709234837.559e3769@bender.Home> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KaGATWMbHYawn9zd" Content-Disposition: inline In-Reply-To: <20130709234837.559e3769@bender.Home> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 03:46:05 -0000 --KaGATWMbHYawn9zd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 09, 2013 at 11:48:37PM +0100, Andrew Turner wrote: > On Tue, 9 Jul 2013 08:19:46 -0600 > Warner Losh wrote: > > I thought that the ELF headers gave us all the data we needed to know > > how things were built... >=20 > It will tell us if it was for e.g. an ARM or MIPS ELF file, but I'm not > sure how we can tell the difference between an arm and an armv6 ELF. >=20 > With armv6 there are a few changes in the userland/kernel > interface, e.g. reading the thread local storage pointer is different > such that an armv6 static binary would not run on an ARMv5 core as it > uses newer instructions. Initially, I thought that you want to differentiate binaries based on the features of the ISA used. I am not aware of any portable convention to do this. For SPARC ISA extensions, Sun invented DT_SUNW_CAP tag. IMHO using tag instead of note is slightly better there. But, your later note suggests that you actually worry about the ABI, and not ISA features, right ? There is EI_OSABI byte in the e_ident member of the ELF header, and you could allocate an new ABI identifier for FREEBSD ARMv6, with corresponding changes in the ELF image activator. Whatever method of branding is used, IMO you should really discuss this with the architecture owners, i.e. ARM. If any other OS would invent similar branding with the different implementation, it is detrimental to the whole arch ecosystem, I think. --KaGATWMbHYawn9zd Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJR3NjyAAoJEJDCuSvBvK1BwYIQAKaNFh2dr632Z+nJ3eZxgQsx M2F/Q+JG8ofg+iYBxr4gw+jir0HftbTTOBSLfiaxPK/efq3LP7eQcTKFHzURPPMY CAPtydAYgebZmUU2NDu6Af825yisYPeSRDZjLgIEwGbGEccRR5DswEOuasFxwI5e PHojW2Qqg1GamjdBRrC3ZNZLrR7J7u9YxX2aqdh1VHW0V/0lzzRcWbgOuVN2B4Gt hyRd2lZ59+KIjFfqstDb5karlV33uFZjC/hb49BRQbydUvsH3aTFiRyNYopfGE77 AfmzUUMsbxOPP0nqJPnVP9WTLZSL3wgWOZnTktNRwFbsNagSMxfNSy0wYR3/Jtxt yFDoTcDQCNsfkxLIY0E5bj2M6fs06iiYdvYWlA6QFLv+Bq3xSoY0U0Vl0cpoNAKG 7Ri18hhLrBbLwo86jh2Cwqw3v/v/WPVIIIA9bEqhaouTjIt37v8OvM3SrfMQucMj MpBhnXURwun8MXtQF4E7iEYDwp7Flx9UOPCBhMN1NVpwz9lYqgfe2gRGsjbENoEC eatET4o7PL8n2seclFh7A3sDPypztvHdAdoW+hR5/xqSQh2wxeV6pcyc683O4VLe OTYg8lhZz7To0Xdn74/pzidzS0fUlHxwk3EzAFyHSQyxtyelAiJF33cDKFWKn57L mmzE9frpbdy+cLZ6gx/p =w6zG -----END PGP SIGNATURE----- --KaGATWMbHYawn9zd-- From owner-freebsd-arch@FreeBSD.ORG Wed Jul 10 04:22:38 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 22C08DA4 for ; Wed, 10 Jul 2013 04:22:38 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-f169.google.com (mail-ie0-f169.google.com [209.85.223.169]) by mx1.freebsd.org (Postfix) with ESMTP id E902D11B8 for ; Wed, 10 Jul 2013 04:22:37 +0000 (UTC) Received: by mail-ie0-f169.google.com with SMTP id 10so14745728ied.28 for ; Tue, 09 Jul 2013 21:22:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=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=zuoa9YFS0LHfc+JOW5kjm3lbCBvpTbZjRGuqFHbJB7k=; b=cRYLjIoaAp7/d5tMO4/K+3G/r6mKhpQRarcOpQWxwDMY0WTuSJ/2HWo/+Qdx31i3mK dVCMKoFilym5jkbB25TXyxTbUVLfSCwFM3Jly7e/JUjHpKMJrV5r9/3ARbVyW6sA78Xv lHnB1t3rYksKmrGSXFsKhXE6gVCb/47Jwyz1O8HmMvO27agmUuioqXpkjyLjRskp95SB lWoSZPumPrrUMXzjU2rVFhWtObiaIIdcsGZAsU3AXc8TvrMt3Nm0hlAPf2Lz5qsevL8U +lGH6F27KbKgrieFI4juRDg+CgkV/DmRK2X4wybp08GXyJ3p827hfUJtU3xjlW9Dj4e/ LLxQ== X-Received: by 10.42.148.5 with SMTP id p5mr9302326icv.19.1373430151707; Tue, 09 Jul 2013 21:22:31 -0700 (PDT) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id fu2sm11419648igb.3.2013.07.09.21.22.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Jul 2013 21:22:30 -0700 (PDT) Sender: Warner Losh Subject: Re: Adding a MACHINE_ARCH note Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20130710034554.GW91021@kib.kiev.ua> Date: Tue, 9 Jul 2013 22:22:29 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <97A960A4-1955-4D6C-8A75-FCBC3CD2DEB7@bsdimp.com> References: <20130709090744.0e497e7e@bender.Home> <32F979BD-FB5C-4111-9586-4C5E7C6DFA71@bsdimp.com> <20130709234837.559e3769@bender.Home> <20130710034554.GW91021@kib.kiev.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQkq2vRmGVhAxnCUElS9HXUCOq6aqXihfCYTAIwBXVDPD8Egox52g2MFYv5YGj1tLulyBNma Cc: Andrew Turner , 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, 10 Jul 2013 04:22:38 -0000 On Jul 9, 2013, at 9:45 PM, Konstantin Belousov wrote: > On Tue, Jul 09, 2013 at 11:48:37PM +0100, Andrew Turner wrote: >> On Tue, 9 Jul 2013 08:19:46 -0600 >> Warner Losh wrote: >>> I thought that the ELF headers gave us all the data we needed to = know >>> how things were built... >>=20 >> It will tell us if it was for e.g. an ARM or MIPS ELF file, but I'm = not >> sure how we can tell the difference between an arm and an armv6 ELF. >>=20 >> With armv6 there are a few changes in the userland/kernel >> interface, e.g. reading the thread local storage pointer is different >> such that an armv6 static binary would not run on an ARMv5 core as it >> uses newer instructions. >=20 > Initially, I thought that you want to differentiate binaries based on = the > features of the ISA used. I am not aware of any portable convention > to do this. For SPARC ISA extensions, Sun invented DT_SUNW_CAP tag. > IMHO using tag instead of note is slightly better there. >=20 > But, your later note suggests that you actually worry about the ABI, > and not ISA features, right ? There is EI_OSABI byte in the e_ident > member of the ELF header, and you could allocate an new ABI identifier > for FREEBSD ARMv6, with corresponding changes in the ELF image > activator. >=20 > Whatever method of branding is used, IMO you should really discuss > this with the architecture owners, i.e. ARM. If any other OS would > invent similar branding with the different implementation, it is > detrimental to the whole arch ecosystem, I think. I posted links to the relevant standards, and there are standard ways to = find this information out from the ELF headers. The only possible issue = is the brandelf issue, which I've not looked into. Warner From owner-freebsd-arch@FreeBSD.ORG Wed Jul 10 05:17:20 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 3223F809; Wed, 10 Jul 2013 05:17:20 +0000 (UTC) (envelope-from gleb.kurtsou@gmail.com) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) by mx1.freebsd.org (Postfix) with ESMTP id 02D671353; Wed, 10 Jul 2013 05:17:19 +0000 (UTC) Received: by mail-pa0-f46.google.com with SMTP id fa11so6356746pad.33 for ; Tue, 09 Jul 2013 22:17:19 -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:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=zqyKdclaqRs8bqOuZSMIljG1I08+BVsXxjqLXp7OWsk=; b=fOGp+o17aa7GSRFqJvN/bd/ArJ9k9kdI01UYGYa2rXEl8vyY1mUz+OV/d/O+NfPaY/ PWhLfb1N80pDUoAArTWD3hjArBuopYVN7wXk5SWWNKNy8UmovQciWSQuea0XlUiS/j2O Uv9N+GpkToIPMu4Gziz0cwk8FdjjW+FmkOdNUobmkpje3ENzawWwdk0g8Ih/L+vd2PI0 p1AVbhO6ArlIpoQO9vtYKZJyvp8P9Pqshjh7jxNZz83DHLqxnZNATq2jIpwQZLjwKLiy 5I+oO2JB2sNpR4vvxGTd/u/+NJxKfIMrR/01RFcgcTO+WQ5R7oZAK5Rt60hT7AuU1JlK 1lkw== X-Received: by 10.68.52.200 with SMTP id v8mr740254pbo.48.1373433439817; Tue, 09 Jul 2013 22:17:19 -0700 (PDT) Received: from localhost (c-67-188-139-74.hsd1.ca.comcast.net. [67.188.139.74]) by mx.google.com with ESMTPSA id 4sm31817485pbw.32.2013.07.09.22.17.18 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 09 Jul 2013 22:17:19 -0700 (PDT) Sender: Gleb Kurtsou Date: Tue, 9 Jul 2013 22:17:38 -0700 From: Gleb Kurtsou To: Warner Losh Subject: Re: ABI change in libkvm (kvm_uread removal) Message-ID: <20130710051738.GA1325@reks> References: <20130709185846.GA19508@gmail.com> <47C53991-4D25-483D-A607-9F2983349481@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <47C53991-4D25-483D-A607-9F2983349481@bsdimp.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Mikolaj Golub , freebsd-arch@freebsd.org, Robert Millan 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, 10 Jul 2013 05:17:20 -0000 On (09/07/2013 14:26), Warner Losh wrote: > > On Jul 9, 2013, at 2:15 PM, Robert Millan wrote: > > The ABI change was detected by Debian build tools during our upgrade > > to FreeBSD 9.1 codebase, which just means we will have to bump the > > soname. > > This is far more interesting than kvm_uread. How hard would it be to somehow bring these tools into FreeBSD to run as part of our build and/or release process? We already have similar tool in tree: /usr/src/tools/tools/shlib-compat Making it part of release process is another story. Thanks, Gleb. From owner-freebsd-arch@FreeBSD.ORG Wed Jul 10 05:24:22 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 C5430AEC; Wed, 10 Jul 2013 05:24:22 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qa0-x235.google.com (mail-qa0-x235.google.com [IPv6:2607:f8b0:400d:c00::235]) by mx1.freebsd.org (Postfix) with ESMTP id 791F61394; Wed, 10 Jul 2013 05:24:22 +0000 (UTC) Received: by mail-qa0-f53.google.com with SMTP id g10so3338014qah.19 for ; Tue, 09 Jul 2013 22:24:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=V+VxNW3KCLD0XCal3weJOTuDSwGxQ3aGP5ZJgku84+Y=; b=biYN09uRLMWw2TNr6Kacud+OaXg3TBxuDqe+GDSenSObmGlFAOFGcWBjw0CcyvLIV1 QVF6LrMF+npYexuZlFEDcxm5mTLu3bnswi3LYGIaRnKdWIB+yIjH3Hru8Re+zyxPt2LJ F8NSvNkQW+Y1f+bg9tf6Yfr8hwhcDrIQWTxHCkHxc40gs3lTmkYksuugunzY2ThK6vef q2sw6rfUnUGfBKRW0luWVTxn/HA3dfgrOxo1SFhzpZAWkxQHinvayxTCFcYT+JYTi4/P V2niH+tYJ4inMvocoDXn3UMD5ZEffi7ywFpLbRFCQvzGfWSEXoRANFjMxenooQ8M9+EX 23dw== MIME-Version: 1.0 X-Received: by 10.49.117.195 with SMTP id kg3mr23928849qeb.68.1373433862094; Tue, 09 Jul 2013 22:24:22 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.195.72 with HTTP; Tue, 9 Jul 2013 22:24:21 -0700 (PDT) In-Reply-To: <82E12BF2-2834-444C-BA24-47DCBF7BD71B@gmail.com> References: <20130704215329.GG1402@garage.freebsd.pl> <20130708213351.GB1405@garage.freebsd.pl> <201307091039.26835.jhb@freebsd.org> <82E12BF2-2834-444C-BA24-47DCBF7BD71B@gmail.com> Date: Tue, 9 Jul 2013 22:24:21 -0700 X-Google-Sender-Auth: IN1bTtnogqb3yKC3_-VtZih-f40 Message-ID: Subject: Re: General purpose library for name/value pairs. From: Adrian Chadd To: Jordan Hubbard Content-Type: text/plain; charset=ISO-8859-1 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, 10 Jul 2013 05:24:22 -0000 On 9 July 2013 18:52, Jordan Hubbard wrote: > > On Jul 9, 2013, at 5:42 PM, Adrian Chadd wrote: > >> You people are evil. I hope you stick to writing gui environments. > > And that, in one sentence, is why FreeBSD STILL has no generalized preference API. Just a bucket of freeform and otherwise disassociated bits in /etc. ;-) Yet you didn't quote my smiley :( -adrian From owner-freebsd-arch@FreeBSD.ORG Wed Jul 10 06:34:12 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 E7976807; Wed, 10 Jul 2013 06:34:12 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-ea0-x22d.google.com (mail-ea0-x22d.google.com [IPv6:2a00:1450:4013:c01::22d]) by mx1.freebsd.org (Postfix) with ESMTP id 54A98173B; Wed, 10 Jul 2013 06:34:12 +0000 (UTC) Received: by mail-ea0-f173.google.com with SMTP id g15so4679647eak.32 for ; Tue, 09 Jul 2013 23:34:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=0MS3NxLAcjx5VrKTBDffh1XhlgDPxyXh6bVLkPM9Wfo=; b=eG+LYcBB3l1D0x6lRwS6tzi9+Q7lIh2ub4CqNGPF65GYzDGeEf3ohRUeuzYmM/lqxN NWoZI05+T9rJ5Y85qDS0ZkkBV/WCZMML1zNb7HNIvs0ngRiUunvr6FK+yWg+qiWawXYL WXUia2HKojuEaCvo2dPqh/U2Ba7OOnfR229lpkhmQjjel0d18/mt5dyqkx+uA0tqdVUr Hc6awa1dnQVfsLI4sb6jVA8AIjMUQWUJpQrgBGM3W1SbI8hr0+MMrve2l5RGpCcmUAlP qPQF7qu064gdbHATiHjaQqqEwx+PLjwLkoMNX+F81dRalkGUS3xvzrB7BxebdhRtd6wH MXXA== X-Received: by 10.14.177.8 with SMTP id c8mr33538983eem.93.1373438051047; Tue, 09 Jul 2013 23:34:11 -0700 (PDT) Received: from localhost ([188.230.122.226]) by mx.google.com with ESMTPSA id cg12sm57302618eeb.7.2013.07.09.23.34.09 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 09 Jul 2013 23:34:10 -0700 (PDT) Date: Wed, 10 Jul 2013 09:34:08 +0300 From: Mikolaj Golub To: Jilles Tjoelker Subject: Re: ABI change in libkvm (kvm_uread removal) Message-ID: <20130710063406.GA39842@gmail.com> References: <20130709185846.GA19508@gmail.com> <20130709211657.GA86400@stack.nl> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="oyUTqETQ0mS9luUI" Content-Disposition: inline In-Reply-To: <20130709211657.GA86400@stack.nl> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-arch@freebsd.org, Robert Millan 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, 10 Jul 2013 06:34:13 -0000 --oyUTqETQ0mS9luUI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Jul 09, 2013 at 11:16:57PM +0200, Jilles Tjoelker wrote: > On Tue, Jul 09, 2013 at 09:59:19PM +0300, Mikolaj Golub wrote: > > Suggestions how this should be fixed properly (if possible) are highly > > appreciated. I will do what people suggest. > > I would suggest bringing back kvm_uread() in stable/9 so that the ABI is > kept. In head, I suggest removing kvm_uread() from the header file and > bumping the soname. I think MFCing the soname bump will cause more > annoyance than the removal of kvm_uread() itself. > > Much of the code using libkvm uses it to access kernel internals, which > are not a proper ABI/API and change fairly frequently. Therefore, it is > probably acceptable for this library not to use symbol versioning. > > The functions that do not expose the caller to kernel internals like > kvm_getprocs() should probably not be used; instead, libprocstat > provides a more ABI-stable way to do the same. Calling the sysctls > directly is also an option. Thank you all for your suggestions. I like Jilles' the most. So I am going to return kvm_uread back to stable/9 by a direct commit and remove it entirely from head and bump soname. -- Mikolaj Golub --oyUTqETQ0mS9luUI Content-Type: text/x-diff; charset=us-ascii Content-Disposition: inline; filename="libkvm.kvm_uread.all.1.patch" Index: head/ObsoleteFiles.inc =================================================================== --- head/ObsoleteFiles.inc (revision 253133) +++ head/ObsoleteFiles.inc (working copy) @@ -38,6 +38,9 @@ # xargs -n1 | sort | uniq -d; # done +# 20130710: libkvm version bump +OLD_LIBS+=lib/libkvm.so.5 +OLD_LIBS+=usr/lib32/libkvm.so.5 # 20130623: dialog update from 1.1 to 1.2 OLD_LIBS+=usr/lib/libdialog.so.7 OLD_LIBS+=usr/lib32/libdialog.so.7 Index: head/lib/libkvm/Makefile =================================================================== --- head/lib/libkvm/Makefile (revision 253133) +++ head/lib/libkvm/Makefile (working copy) @@ -3,6 +3,7 @@ LIB= kvm SHLIBDIR?= /lib +SHLIB_MAJOR= 6 CFLAGS+=-DLIBC_SCCS -I${.CURDIR} .if exists(${.CURDIR}/kvm_${MACHINE_ARCH}.c) Index: head/lib/libkvm/kvm.h =================================================================== --- head/lib/libkvm/kvm.h (revision 253133) +++ head/lib/libkvm/kvm.h (working copy) @@ -89,8 +89,6 @@ kvm_t *kvm_openfiles (const char *, const char *, const char *, int, char *); ssize_t kvm_read(kvm_t *, unsigned long, void *, size_t); ssize_t kvm_read_zpcpu(kvm_t *, void *, u_long, size_t, int); -ssize_t kvm_uread - (kvm_t *, const struct kinfo_proc *, unsigned long, char *, size_t); ssize_t kvm_write(kvm_t *, unsigned long, const void *, size_t); __END_DECLS Index: stable/9/lib/libkvm/kvm_proc.c =================================================================== --- stable/9/lib/libkvm/kvm_proc.c (revision 253133) +++ stable/9/lib/libkvm/kvm_proc.c (working copy) @@ -712,3 +712,55 @@ kvm_getenvv(kvm_t *kd, const struct kinfo_proc *kp { return (kvm_argv(kd, kp, 1, nchr)); } + +/* + * Read from user space. The user context is given by p. + */ +ssize_t +kvm_uread(kvm_t *kd, const struct kinfo_proc *kp, u_long uva, char *buf, + size_t len) +{ + char *cp; + char procfile[MAXPATHLEN]; + ssize_t amount; + int fd; + + if (!ISALIVE(kd)) { + _kvm_err(kd, kd->program, + "cannot read user space from dead kernel"); + return (0); + } + + sprintf(procfile, "/proc/%d/mem", kp->ki_pid); + fd = open(procfile, O_RDONLY, 0); + if (fd < 0) { + _kvm_err(kd, kd->program, "cannot open %s", procfile); + return (0); + } + + cp = buf; + while (len > 0) { + errno = 0; + if (lseek(fd, (off_t)uva, 0) == -1 && errno != 0) { + _kvm_err(kd, kd->program, "invalid address (%lx) in %s", + uva, procfile); + break; + } + amount = read(fd, cp, len); + if (amount < 0) { + _kvm_syserr(kd, kd->program, "error reading %s", + procfile); + break; + } + if (amount == 0) { + _kvm_err(kd, kd->program, "EOF reading %s", procfile); + break; + } + cp += amount; + uva += amount; + len -= amount; + } + + close(fd); + return ((ssize_t)(cp - buf)); +} --oyUTqETQ0mS9luUI-- From owner-freebsd-arch@FreeBSD.ORG Wed Jul 10 06:44:14 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 0D8EF94F for ; Wed, 10 Jul 2013 06:44:14 +0000 (UTC) (envelope-from peter@wemm.org) Received: from mail-vc0-x234.google.com (mail-vc0-x234.google.com [IPv6:2607:f8b0:400c:c03::234]) by mx1.freebsd.org (Postfix) with ESMTP id C2696178A for ; Wed, 10 Jul 2013 06:44:13 +0000 (UTC) Received: by mail-vc0-f180.google.com with SMTP id gf11so5036340vcb.11 for ; Tue, 09 Jul 2013 23:44:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5KdcLwtWEsrPrz3L5/CkeEZo/iw9texiUl5ix1tS6Jw=; b=1v/g8RfbaYV5/1N/KQknWozwK1rHgL1VfUy49YpMg5jZfSfcryFdjM4ktYPutOe0zv WnuIP7WMJvongSXqHEWRWpYG1qj+L+hOw+0+CRl3K5/sQPb4tvqdL8f6YvBelCW2Nu/q lroE/RZmi0kSoBWKCzAFWMvYvzE+/CN5vHN8M= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=5KdcLwtWEsrPrz3L5/CkeEZo/iw9texiUl5ix1tS6Jw=; b=FHh0tzmpl+kSZNNHfO879O0ixrhpSF65H6XyM/PtaV3se3hFPQ312AoLeNWGULKmEG UHUy0pMmo+w6BMxnkIAneTYrJHCEKPixIGyoWxdnPvB8c92XsaHAloqwjqXSqFy3tGd5 RuD2tn4ksL+tmLBR6ZQnC2XZbh1jqv4Zvl3Y3WG88UqDtK7CKOT4rEaSmBkwzL8oXB67 h4elmeSM+CqTeSr6dqSh3qxhpWhCX3oY4Y71Y8YDU89tgmk67to1ETII8UYfhnvjz5/o uNhNbwZEoiDM4TzULq8spciDNNJHV/0MQlhDM65+kcKJ5IwTJuAHZ63s/n019ytSmzgy MtsA== MIME-Version: 1.0 X-Received: by 10.52.65.111 with SMTP id w15mr14839784vds.73.1373438653298; Tue, 09 Jul 2013 23:44:13 -0700 (PDT) Received: by 10.221.37.198 with HTTP; Tue, 9 Jul 2013 23:44:13 -0700 (PDT) In-Reply-To: <20130710063406.GA39842@gmail.com> References: <20130709185846.GA19508@gmail.com> <20130709211657.GA86400@stack.nl> <20130710063406.GA39842@gmail.com> Date: Tue, 9 Jul 2013 23:44:13 -0700 Message-ID: Subject: Re: ABI change in libkvm (kvm_uread removal) From: Peter Wemm To: Mikolaj Golub Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkJOLx1E6LcFKc7gcDQcgvO3YwmyaJlfA1wtdF92yrF1jts6ClyJRrrWrrfzEIfEDFzZL2X Cc: freebsd-arch@freebsd.org, Jilles Tjoelker , Robert Millan 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, 10 Jul 2013 06:44:14 -0000 On Tue, Jul 9, 2013 at 11:34 PM, Mikolaj Golub wrote: > On Tue, Jul 09, 2013 at 11:16:57PM +0200, Jilles Tjoelker wrote: >> On Tue, Jul 09, 2013 at 09:59:19PM +0300, Mikolaj Golub wrote: >> > Suggestions how this should be fixed properly (if possible) are highly >> > appreciated. I will do what people suggest. >> >> I would suggest bringing back kvm_uread() in stable/9 so that the ABI is >> kept. In head, I suggest removing kvm_uread() from the header file and >> bumping the soname. I think MFCing the soname bump will cause more >> annoyance than the removal of kvm_uread() itself. >> >> Much of the code using libkvm uses it to access kernel internals, which >> are not a proper ABI/API and change fairly frequently. Therefore, it is >> probably acceptable for this library not to use symbol versioning. >> >> The functions that do not expose the caller to kernel internals like >> kvm_getprocs() should probably not be used; instead, libprocstat >> provides a more ABI-stable way to do the same. Calling the sysctls >> directly is also an option. > > Thank you all for your suggestions. I like Jilles' the most. So I am > going to return kvm_uread back to stable/9 by a direct commit and > remove it entirely from head and bump soname. Have you confirmed that the code you're about to add back actually works? -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV UTF-8: So you can \342\200\231 .. for when a ' just won't do ZFS must be the bacon of file systems. "everything's better with ZFS" From owner-freebsd-arch@FreeBSD.ORG Wed Jul 10 06:54: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 442BEF4A; Wed, 10 Jul 2013 06:54:09 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) by mx1.freebsd.org (Postfix) with ESMTP id 032BB17EE; Wed, 10 Jul 2013 06:54:08 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::f9f8:ee16:c79c:c973] (unknown [IPv6:2001:7b8:3a7:0:f9f8:ee16:c79c:c973]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id E0C735C43; Wed, 10 Jul 2013 08:54:05 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: Adding a MACHINE_ARCH note From: Dimitry Andric In-Reply-To: Date: Wed, 10 Jul 2013 08:54:05 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <20130709090744.0e497e7e@bender.Home> <32F979BD-FB5C-4111-9586-4C5E7C6DFA71@bsdimp.com> <20130709234837.559e3769@bender.Home> To: Peter Wemm X-Mailer: Apple Mail (2.1508) Cc: Adrian Chadd , freebsd-arch@freebsd.org, Baptiste Daroussin , Andrew Turner 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, 10 Jul 2013 06:54:09 -0000 On Jul 10, 2013, at 03:08, Peter Wemm wrote: > On Tue, Jul 9, 2013 at 5:56 PM, Adrian Chadd wrote: >> ... boy I'd like to see this particular x86 hiccup fixed before this >> stuff is mainstream. > > I'm not entirely sure how much support there is behind "x32". I don't > know if its much more than an academic curiosity or if there's real > demand for it. It seems to be driven by Intel and Google. The idea is that for some applications (or maybe even most :), an ILP32 model will perform better. Quoting from one of the presentations: On Core i7 2600K 3.40GHz: - Improved SPEC CPU 2K/2006 INT geomean by 7-10% over ia32 and 5-8% over Intel64. - Improved SPEC CPU 2K/2006 FP geomean by 5-11% over ia32. - Very little changes in SPEC CPU 2K/2006 FP geomean, comparing against Intel64. - Comparing against ia32 PIC, x32 PIC: - Improved SPEC CPU 2K INT by another 10%. - Improved SPEC CPU 2K FP by another 3%. - Improved SPEC CPU 2006 INT by another 6% - Improved SPEC CPU 2006 FP by another 2%. As to how often it is actually used in practice, I am not sure. > gcc-4.8 and clang have it, or have patches for it. You also need a fairly recent binutils. And kernel + libc support... It is probably not a trivial task. :-) -Dimitry From owner-freebsd-arch@FreeBSD.ORG Wed Jul 10 07:03:24 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 7D4494A1; Wed, 10 Jul 2013 07:03:24 +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 E0DEF1844; Wed, 10 Jul 2013 07:03:23 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r6A73KDc051742; Wed, 10 Jul 2013 10:03:20 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r6A73KDc051742 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r6A73KXv051741; Wed, 10 Jul 2013 10:03:20 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 10 Jul 2013 10:03:19 +0300 From: Konstantin Belousov To: Dimitry Andric Subject: Re: Adding a MACHINE_ARCH note Message-ID: <20130710070319.GX91021@kib.kiev.ua> References: <20130709090744.0e497e7e@bender.Home> <32F979BD-FB5C-4111-9586-4C5E7C6DFA71@bsdimp.com> <20130709234837.559e3769@bender.Home> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tWkvZsi8Zj/QU8J/" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: Adrian Chadd , Andrew Turner , Baptiste Daroussin , 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, 10 Jul 2013 07:03:24 -0000 --tWkvZsi8Zj/QU8J/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 10, 2013 at 08:54:05AM +0200, Dimitry Andric wrote: > On Jul 10, 2013, at 03:08, Peter Wemm wrote: > > On Tue, Jul 9, 2013 at 5:56 PM, Adrian Chadd wrote: > >> ... boy I'd like to see this particular x86 hiccup fixed before this > >> stuff is mainstream. > >=20 > > I'm not entirely sure how much support there is behind "x32". I don't > > know if its much more than an academic curiosity or if there's real > > demand for it. >=20 > It seems to be driven by Intel and Google. The idea is that for some > applications (or maybe even most :), an ILP32 model will perform better. > Quoting from one of the presentations: >=20 > On Core i7 2600K 3.40GHz: > - Improved SPEC CPU 2K/2006 INT geomean by 7-10% over ia32 and 5-8% over > Intel64. > - Improved SPEC CPU 2K/2006 FP geomean by 5-11% over ia32. > - Very little changes in SPEC CPU 2K/2006 FP geomean, comparing against > Intel64. > - Comparing against ia32 PIC, x32 PIC: > - Improved SPEC CPU 2K INT by another 10%. > - Improved SPEC CPU 2K FP by another 3%. > - Improved SPEC CPU 2006 INT by another 6% > - Improved SPEC CPU 2006 FP by another 2%. >=20 > As to how often it is actually used in practice, I am not sure. >=20 >=20 > > gcc-4.8 and clang have it, or have patches for it. >=20 > You also need a fairly recent binutils. And kernel + libc support... > It is probably not a trivial task. :-) You definitely need a support from libc, libthr and rtld. I am not convinced that the kernel modifications are needed, except for the image activator to recognize new ELF ids. In other words, I believe it is better to put shims into libc in the long run. --tWkvZsi8Zj/QU8J/ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJR3Qc3AAoJEJDCuSvBvK1BXe8P/jZ604xf7KW+UomlRISkVuaZ ye3QQLrvoMmnRYpNiLBnJ0l3RUP/qDlRCtqTopo2f1cEo0SyXZO1b3IpFXwLZwkS L5sTOjL2IB1nSXUgQ2tQXz9uu5njwmXYapQgLXseX+9dnS6iWQeWV8+RbrgR0Ul+ ifxQ9VUaV6/97caKu7NpwWs+BVcqBtPV0DHLmvUQWChSBFpHdQdnlsb5a7YF8G5k RAycGYO0Fb8jmLOMvWDnfWbejjvfFkdJPwX71YZ6haumYBVSwC5Uj1bdBtzubzBj MFkaGHua/RrAfjiW+tTpmzCsEpxuF7ZQcBiRXM2YW8y423Wz4e++MLde7eiMa0bw ZW97IJzwIr8FO+qcZi1ELvjwpeXsaiLUEpXHi/V8oNwocp0CcEnqVmpa9K/dEN8d 3UcebAToLRsbgeLv3UbmNIRq2V6K68Vz2WoSucYGwMfkk9Qd/uyhdh2DU7YF94Sl qxLCJyUcxpjMelTLy8MV/gjrg3/tDcgl8JtCmY75RPSgzI8rO1hIJJamdXMUvHml WYr0UM4vgiojkRm9wevxNGcPuFsaT/XSCoe5cprdq9qqXxXvLVrpLd9j/RpMuBhd pXzDYvfc1C23/YkB/KeEX8WqxzbkD4nDVxRIA2Fyf8iIHgJSRSAg2cmSqNG+E57s BjUytoPT7HWq21RaUcu1 =uUfA -----END PGP SIGNATURE----- --tWkvZsi8Zj/QU8J/-- From owner-freebsd-arch@FreeBSD.ORG Wed Jul 10 08:43:25 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 CD0091AD; Wed, 10 Jul 2013 08:43:25 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail109.syd.optusnet.com.au (mail109.syd.optusnet.com.au [211.29.132.80]) by mx1.freebsd.org (Postfix) with ESMTP id 77F481C5D; Wed, 10 Jul 2013 08:43:25 +0000 (UTC) Received: from c122-106-156-23.carlnfd1.nsw.optusnet.com.au (c122-106-156-23.carlnfd1.nsw.optusnet.com.au [122.106.156.23]) by mail109.syd.optusnet.com.au (Postfix) with ESMTPS id 1B751123291; Wed, 10 Jul 2013 18:43:23 +1000 (EST) Date: Wed, 10 Jul 2013 18:43:22 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Konstantin Belousov Subject: Re: Adding a MACHINE_ARCH note In-Reply-To: <20130710070319.GX91021@kib.kiev.ua> Message-ID: <20130710182855.Y1991@besplex.bde.org> References: <20130709090744.0e497e7e@bender.Home> <32F979BD-FB5C-4111-9586-4C5E7C6DFA71@bsdimp.com> <20130709234837.559e3769@bender.Home> <20130710070319.GX91021@kib.kiev.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.0 cv=eqSHVfVX c=1 sm=1 a=EaX08ZwJ5LAA:10 a=kj9zAlcOel0A:10 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=AaSZaHyH4e8A:10 a=5o0Kwa6bAAAA:8 a=6I5d2MoRAAAA:8 a=0A_dmAVHAkkNKtFbODsA:9 a=CjuIK1q_8ugA:10 a=2IDN0xrzlfsA:10 a=SV7veod9ZcQA:10 a=ebeQFi2P/qHVC0Yw9JDJ4g==:117 Cc: Baptiste Daroussin , Adrian Chadd , Dimitry Andric , Andrew Turner , 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, 10 Jul 2013 08:43:25 -0000 On Wed, 10 Jul 2013, Konstantin Belousov wrote: > On Wed, Jul 10, 2013 at 08:54:05AM +0200, Dimitry Andric wrote: >> On Jul 10, 2013, at 03:08, Peter Wemm wrote: >>> On Tue, Jul 9, 2013 at 5:56 PM, Adrian Chadd wrote: >>>> ... boy I'd like to see this particular x86 hiccup fixed before this >>>> stuff is mainstream. >>> >>> I'm not entirely sure how much support there is behind "x32". I don't >>> know if its much more than an academic curiosity or if there's real >>> demand for it. >> >> It seems to be driven by Intel and Google. The idea is that for some >> applications (or maybe even most :), an ILP32 model will perform better. >> Quoting from one of the presentations: >> >> On Core i7 2600K 3.40GHz: >> - Improved SPEC CPU 2K/2006 INT geomean by 7-10% over ia32 and 5-8% over >> Intel64. >> - Improved SPEC CPU 2K/2006 FP geomean by 5-11% over ia32. >> - Very little changes in SPEC CPU 2K/2006 FP geomean, comparing against >> Intel64. >> - Comparing against ia32 PIC, x32 PIC: >> - Improved SPEC CPU 2K INT by another 10%. >> - Improved SPEC CPU 2K FP by another 3%. >> - Improved SPEC CPU 2006 INT by another 6% >> - Improved SPEC CPU 2006 FP by another 2%. >> >> As to how often it is actually used in practice, I am not sure. >> >>> gcc-4.8 and clang have it, or have patches for it. >> >> You also need a fairly recent binutils. And kernel + libc support... >> It is probably not a trivial task. :-) > > You definitely need a support from libc, libthr and rtld. > I am not convinced that the kernel modifications are needed, > except for the image activator to recognize new ELF ids. In > other words, I believe it is better to put shims into libc in > the long run. ISTR reading a claim that pure 64-bit mode was mainly a marketing ploy by AMD. It distinguished them from Intel and let them get to market faster. The result was a marketing win but a not so good instruction set architecture. This was contrasted with sparc64 (Sun?), where 32-bit applications remained the default and the differences were smaller (no mode switch?). Bruce From owner-freebsd-arch@FreeBSD.ORG Wed Jul 10 09:15: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 74BCD934; Wed, 10 Jul 2013 09:15:25 +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 167BA1DD1; Wed, 10 Jul 2013 09:15:24 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r6A9FE9S078864; Wed, 10 Jul 2013 12:15:15 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r6A9FE9S078864 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r6A9FErs078863; Wed, 10 Jul 2013 12:15:14 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 10 Jul 2013 12:15:14 +0300 From: Konstantin Belousov To: Bruce Evans Subject: Re: Adding a MACHINE_ARCH note Message-ID: <20130710091514.GA91021@kib.kiev.ua> References: <20130709090744.0e497e7e@bender.Home> <32F979BD-FB5C-4111-9586-4C5E7C6DFA71@bsdimp.com> <20130709234837.559e3769@bender.Home> <20130710070319.GX91021@kib.kiev.ua> <20130710182855.Y1991@besplex.bde.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jK4jXyj6WYQn7qqq" Content-Disposition: inline In-Reply-To: <20130710182855.Y1991@besplex.bde.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: Baptiste Daroussin , Adrian Chadd , Dimitry Andric , Andrew Turner , 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, 10 Jul 2013 09:15:25 -0000 --jK4jXyj6WYQn7qqq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 10, 2013 at 06:43:22PM +1000, Bruce Evans wrote: >=20 > ISTR reading a claim that pure 64-bit mode was mainly a marketing ploy > by AMD. It distinguished them from Intel and let them get to market > faster. The result was a marketing win but a not so good instruction > set architecture. This was contrasted with sparc64 (Sun?), where > 32-bit applications remained the default and the differences were > smaller (no mode switch?). Sparcv8 did not have an issue with the very limited size of the register file. They did not need to change instruction encoding to allow bigger set of the registers. Amd had to change encoding, and indeed I remember reading somewhere that they decided to not allow the REX prefix for compatibility mode to push the "full" 64bit tagline. Solaris port to amd64 is very similar to sparcv9: almost all usermode binaries are 32 bit, libraries are supplied in both 32 and 64 bit versions, compiler defaults to -m32. Only several binaries are 64 bit, most notable are procfs tools and debugger. There is no reason why such approach could not been taken for the FreeBSD port, except convenience and avoiding the work for properly support all kernel interfaces in compat 32bit and 64bit variants from the beginning. We still have almost no compat32 for the management interfaces, esp. network. cc -m32 works in HEAD. I believe that multiarch for ports is not even thought about, would be very happy to be wrong there. --jK4jXyj6WYQn7qqq Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJR3SYiAAoJEJDCuSvBvK1B3XcQAIf5OI4DGGAnorMdz4wz/615 oWP8NmldYA834fnAnxtWjvSbDorcJolGKAQ05Q39cPfUFsuiKwN5n+ZZF8gveG3w ltWNYN5J9o09K/FDuQOK9yXV1VsQArtfW05cgxvdt8Gu+q6FbsL+LeSvULxJ6jL+ HoI90UO3fjw4GD+SLAaiDwAYOyaoX13gQiRUqXDqFQd0Y3E3JYk7lkx0WzOupgCy cBXPS+w6QUVWfL9ynNDIwcwWrt0judQF56s2sp3ilYj9iENDysTttPhUnP+JJit/ SztVS945Wh6yvjYhTdTgcd6Ckx1OpCqxd8j5WEGpgPGkXe9C+MpR/KkL0F0SZQ8G HQatqHr5+m17s/MxBrIXPdytBA49j7TnN2kVkYmOBz2kvxUn/25fu0Y33j5zc7Vk 2XnHja9/tkjtSwve7il3urgXtx3A1NtMZtW0sYcE5BnAD6vSUB3RB4qHynxjbbB/ 1TK1Dhtxm31/xO4UxM+gBr0epYm8xf1IEURxGUxP7klx4Q2rkegWih9GGRf2Spkj F9LkGcUOojuKTWR7p6ok6qmtBdee6jUk8F3mNWz0DMdow0x+AennEAx8S2oesyD+ VCo3KDaenAHZebgcpXzgpE51zSxz1hzFsOBHzHOM72QFMJABQgxpgUoUqVq9WKrU mrt82sgru2mv42v6Hkfz =jBHK -----END PGP SIGNATURE----- --jK4jXyj6WYQn7qqq-- From owner-freebsd-arch@FreeBSD.ORG Wed Jul 10 09:20: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 F3B04BBC; Wed, 10 Jul 2013 09:20:50 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-ea0-x234.google.com (mail-ea0-x234.google.com [IPv6:2a00:1450:4013:c01::234]) by mx1.freebsd.org (Postfix) with ESMTP id 632521E33; Wed, 10 Jul 2013 09:20:50 +0000 (UTC) Received: by mail-ea0-f180.google.com with SMTP id k10so4820384eaj.25 for ; Wed, 10 Jul 2013 02:20:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=0ne+vH6TYD1W3VQAMI4nZjrK5FdE1qxvtID5+w5+pJM=; b=izEcPnNRpJ/AMaRb2AIm5esjc6QfVCGeqraMzEpZoJGRwsUFkdxCAKEtN0iuUAeXth ifmY5h3FL2bTVuOhdCYFh+lh7bllTOLe5LkX3sR9YVwRFLHRu37hOrd1FeLCFzrzImTC mDN71Nmx6HlNFzCSQ4Y/fcBbwnVz474X2TTrZ3rzk8RTmQBGWMdwnmfS/MV/vipCs9TB fpXAvPnX5tjImc/eodRJoe9viXGAknXGBqAQXU/rnnwtHs3qT8rphFXoUvEz3ZyV35qI namTWpW+8HG8zSDpwr/HAvm5OVwqcY7ZdNmUJ4vPZCzGUyQSyegYLQym1OIPmK/hzCil xeYA== X-Received: by 10.14.103.196 with SMTP id f44mr34805858eeg.37.1373448049461; Wed, 10 Jul 2013 02:20:49 -0700 (PDT) Received: from localhost ([188.230.122.226]) by mx.google.com with ESMTPSA id y1sm58426922eew.3.2013.07.10.02.20.47 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 10 Jul 2013 02:20:48 -0700 (PDT) Date: Wed, 10 Jul 2013 12:20:46 +0300 From: Mikolaj Golub To: Peter Wemm Subject: Re: ABI change in libkvm (kvm_uread removal) Message-ID: <20130710092045.GB39842@gmail.com> References: <20130709185846.GA19508@gmail.com> <20130709211657.GA86400@stack.nl> <20130710063406.GA39842@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-arch@freebsd.org, Jilles Tjoelker , Robert Millan 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, 10 Jul 2013 09:20:51 -0000 On Tue, Jul 09, 2013 at 11:44:13PM -0700, Peter Wemm wrote: > Have you confirmed that the code you're about to add back actually > works? It works for this simple test: http://people.freebsd.org/~trociny/tmp/test_kvm_uread.c -- Mikolaj Golub From owner-freebsd-arch@FreeBSD.ORG Wed Jul 10 13:55:57 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 BB92B9AF for ; Wed, 10 Jul 2013 13:55:57 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-f180.google.com (mail-ie0-f180.google.com [209.85.223.180]) by mx1.freebsd.org (Postfix) with ESMTP id 896011F2C for ; Wed, 10 Jul 2013 13:55:57 +0000 (UTC) Received: by mail-ie0-f180.google.com with SMTP id f4so15381911iea.11 for ; Wed, 10 Jul 2013 06:55:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=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=07nk/aQWme3MiNCM8C94h2ngEPDYhO9qA/WkznsrLyI=; b=XDmGR7Q6K/l4In5/T3+kROrRZWe8vELsj0GiwFOiBM/uLbWy2e7PyoPKTUDWMidomU nKsMMBI/1Y8Zo2rc2TppX37HSOl8LiQzOLmRg0TvdggcOMQTk5v1RbUGV7TZik7gMl/t U8FNMvgFjdn0TrMCwcprMEZUezhjAhdFUshTgalXFDWzYPKv8sZrZx4FCV0tYRIzAFg0 pXWBx12Pj6lPYCnZEeLfgon2tD7c/XOZMCbXzNDkWVsl540RkWq0yozRGzPMWse2Cmzk UI71aNEgPjw3AmKr/lKqgdulXRokGj/nVG9XSkeKFsdUCNhX+y3ToBbx7S7H+JDuiLht iORw== X-Received: by 10.42.62.198 with SMTP id z6mr10111155ich.7.1373464556941; Wed, 10 Jul 2013 06:55:56 -0700 (PDT) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id ri10sm37567907igc.1.2013.07.10.06.55.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 10 Jul 2013 06:55:55 -0700 (PDT) Sender: Warner Losh Subject: Re: Adding a MACHINE_ARCH note Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20130710070319.GX91021@kib.kiev.ua> Date: Wed, 10 Jul 2013 07:55:53 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130709090744.0e497e7e@bender.Home> <32F979BD-FB5C-4111-9586-4C5E7C6DFA71@bsdimp.com> <20130709234837.559e3769@bender.Home> <20130710070319.GX91021@kib.kiev.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQlv7eMziarww0sXaFzViCIV8Y4jqMzwTl1gVhC4VkfTy+vMle1Btg4ejE6ZcB07JNfJ0DXS Cc: Baptiste Daroussin , Adrian Chadd , Dimitry Andric , Andrew Turner , 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, 10 Jul 2013 13:55:57 -0000 On Jul 10, 2013, at 1:03 AM, Konstantin Belousov wrote: > On Wed, Jul 10, 2013 at 08:54:05AM +0200, Dimitry Andric wrote: >> On Jul 10, 2013, at 03:08, Peter Wemm wrote: >>> On Tue, Jul 9, 2013 at 5:56 PM, Adrian Chadd = wrote: >>>> ... boy I'd like to see this particular x86 hiccup fixed before = this >>>> stuff is mainstream. >>>=20 >>> I'm not entirely sure how much support there is behind "x32". I = don't >>> know if its much more than an academic curiosity or if there's real >>> demand for it. >>=20 >> It seems to be driven by Intel and Google. The idea is that for some >> applications (or maybe even most :), an ILP32 model will perform = better. >> Quoting from one of the presentations: >>=20 >> On Core i7 2600K 3.40GHz: >> - Improved SPEC CPU 2K/2006 INT geomean by 7-10% over ia32 and 5-8% = over >> Intel64. >> - Improved SPEC CPU 2K/2006 FP geomean by 5-11% over ia32. >> - Very little changes in SPEC CPU 2K/2006 FP geomean, comparing = against >> Intel64. >> - Comparing against ia32 PIC, x32 PIC: >> - Improved SPEC CPU 2K INT by another 10%. >> - Improved SPEC CPU 2K FP by another 3%. >> - Improved SPEC CPU 2006 INT by another 6% >> - Improved SPEC CPU 2006 FP by another 2%. >>=20 >> As to how often it is actually used in practice, I am not sure. >>=20 >>=20 >>> gcc-4.8 and clang have it, or have patches for it. >>=20 >> You also need a fairly recent binutils. And kernel + libc support... >> It is probably not a trivial task. :-) >=20 > You definitely need a support from libc, libthr and rtld. > I am not convinced that the kernel modifications are needed, > except for the image activator to recognize new ELF ids. In > other words, I believe it is better to put shims into libc in > the long run. For MIPS N32, you also need to make sure that the system calls grok the = ABI. You're going to give up some of the performance gains by shimming, = plus you run the risk of mixing x32 with amd64 code, which would be bad. = Attractive as it may sound to try to put it all in libc, I'm not = convinced that would work out in the end. Warner= From owner-freebsd-arch@FreeBSD.ORG Wed Jul 10 16:41:20 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 6E79E37A; Wed, 10 Jul 2013 16:41:20 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qa0-x235.google.com (mail-qa0-x235.google.com [IPv6:2607:f8b0:400d:c00::235]) by mx1.freebsd.org (Postfix) with ESMTP id 09F811CCB; Wed, 10 Jul 2013 16:41:19 +0000 (UTC) Received: by mail-qa0-f53.google.com with SMTP id g10so3687704qah.12 for ; Wed, 10 Jul 2013 09:41:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=+yLS9dpa61HZ6csTYjOH5jRvvap/wZFBAwDU4VCHV8c=; b=YzVsnvQzWcNd2OwyYRo8i59xeYg0iT46x0iNogzflLFWA99TRaTldJgbFbueWdDl3d Hs5+cRa6FTRjB1dmLDoaR3fLTla9kG6YjaLecBTt0xte49LzeXHBj7ugOxrTKKZNGl64 K/JecVEtY4ywiZlRPLemwORWwXFyFGja0PGlJf1nb63YJvow0sQTzPs0B5GArIUU/knX vaZyIsVW2xM8Mz51cuDB6vKp+3+iQyC0LfneIwtfb46kagV/tE+NM+FqClRga3I1cki1 AKWldXXExa3hAU4ZAMN6r45WimyCqg9Irn5ys/YN1YoJ87ZD95bxpbqdQiKCKBcW8mxO nf+A== MIME-Version: 1.0 X-Received: by 10.49.110.68 with SMTP id hy4mr26010418qeb.6.1373474479474; Wed, 10 Jul 2013 09:41:19 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.195.72 with HTTP; Wed, 10 Jul 2013 09:41:19 -0700 (PDT) In-Reply-To: References: <20130709090744.0e497e7e@bender.Home> <32F979BD-FB5C-4111-9586-4C5E7C6DFA71@bsdimp.com> <20130709234837.559e3769@bender.Home> Date: Wed, 10 Jul 2013 09:41:19 -0700 X-Google-Sender-Auth: NsPdmrjwj80Vh3fbThcZidcpQ74 Message-ID: Subject: Re: Adding a MACHINE_ARCH note From: Adrian Chadd To: Dimitry Andric Content-Type: text/plain; charset=ISO-8859-1 Cc: Baptiste Daroussin , Andrew Turner , 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, 10 Jul 2013 16:41:20 -0000 [snip] .. boy, wouldn't it be nice to at least check if the package system we're about to roll out may support this? That's the reason I replied about it. Not specifically to make it happen _everywhere_, but to see if we're about to migrate to a tool that doesn't support it, making it a much bigger deal to migrate again later. -adrian From owner-freebsd-arch@FreeBSD.ORG Wed Jul 10 16:55:29 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 748B8992 for ; Wed, 10 Jul 2013 16:55:29 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-f179.google.com (mail-ie0-f179.google.com [209.85.223.179]) by mx1.freebsd.org (Postfix) with ESMTP id 432861D8B for ; Wed, 10 Jul 2013 16:55:29 +0000 (UTC) Received: by mail-ie0-f179.google.com with SMTP id c10so16331580ieb.10 for ; Wed, 10 Jul 2013 09:55:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=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=3WwhEESNvjmrYsgMnEjXaqxBUoV/h14ecXFvPpfkeVM=; b=oXK814IcwjurUs6lisGMX0xxch/WzqyIdqzDYi7qZb32daJP+AC/FRX1U5Vi2Q2nvY jes3QubIvbfWqXHnGqUw7MSL+jBDfap22zaMvZ3ASCE1qMPpl6Mk0+Ri/UKvpD2e7BL7 5R/60USp+zheG5J52aIy6v+FOdWcb4k3OzI0RPUlx/MwrAXiHXRGTLmPZwl1dEn5z2YH ZCk/NjneMDNz6FxQsnIMmScBC6XD+wYWhGZmvfShY5jnWXw6lv5GSUSyFrgj+fVvtpb/ GAcRBbqRU88C855c+wj9m0o6uFDRCxrM8iRRsbfOjaNUEH1A92mPoQK9wQtNI2KZfxvE PNwQ== X-Received: by 10.50.23.8 with SMTP id i8mr35990261igf.42.1373475323601; Wed, 10 Jul 2013 09:55:23 -0700 (PDT) Received: from monkey-bot.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPSA id nr4sm12133988igb.0.2013.07.10.09.55.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 10 Jul 2013 09:55:22 -0700 (PDT) Sender: Warner Losh Subject: Re: Adding a MACHINE_ARCH note Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Wed, 10 Jul 2013 10:55:20 -0600 Content-Transfer-Encoding: 7bit Message-Id: <752588A3-C0EF-4844-A0EE-4657CAD40E4C@bsdimp.com> References: <20130709090744.0e497e7e@bender.Home> <32F979BD-FB5C-4111-9586-4C5E7C6DFA71@bsdimp.com> <20130709234837.559e3769@bender.Home> To: Adrian Chadd X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQkuHBNLXLawknsAJLdtMZxaEq/mzcxFBmSe/3ZGiOxyXQ/XrzfY7gLHjBpUzXhmqlX1010g Cc: Baptiste Daroussin , Dimitry Andric , Andrew Turner , 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, 10 Jul 2013 16:55:29 -0000 On Jul 10, 2013, at 10:41 AM, Adrian Chadd wrote: > [snip] > > .. boy, wouldn't it be nice to at least check if the package system > we're about to roll out may support this? > > That's the reason I replied about it. Not specifically to make it > happen _everywhere_, but to see if we're about to migrate to a tool > that doesn't support it, making it a much bigger deal to migrate again > later. I've been talking to Baptiste, and it will support this. Warner From owner-freebsd-arch@FreeBSD.ORG Wed Jul 10 19:26: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 31A60AB0; Wed, 10 Jul 2013 19:26:43 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qe0-x231.google.com (mail-qe0-x231.google.com [IPv6:2607:f8b0:400d:c02::231]) by mx1.freebsd.org (Postfix) with ESMTP id C4A411701; Wed, 10 Jul 2013 19:26:42 +0000 (UTC) Received: by mail-qe0-f49.google.com with SMTP id cz11so3908486qeb.22 for ; Wed, 10 Jul 2013 12:26:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=UbZ8VBt+CIy1H+Ik2eLcyzABAGwpbOeHBDvSJsk5ohs=; b=zUtxUIC5DAWDSwlZIsDl4BaQots8IcuLpCdHg8Pb39W4f6Vsd+UOvkMTEDRtBKSiEg RgABq3+o+mu/gJFv14/bY/760/3F3E4p9v6DKGvCDfOJRBdGAb/SJ/mQq690tkTgUjSP TlcAf/jpMRBT/3sStUeAaBZibBh5JIBexiiOFyZV+5QKlp4rPI9XPtIjGJ0Wrp+QWRGU BOu9/W6bKAhQnVb5lQdq+Lnh/P17gl0i/XeXdlIUvX6Em+S4rq++j0w/JCc0f7biFM4G DVAWiqeX1GjxBqJLOb/TPbNJs+SJE1Px4XQgTs4OPJRJRcJR0w2bzLMgkPW01KAPgXgV xF5A== MIME-Version: 1.0 X-Received: by 10.49.117.195 with SMTP id kg3mr26986656qeb.68.1373484402343; Wed, 10 Jul 2013 12:26:42 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.195.72 with HTTP; Wed, 10 Jul 2013 12:26:42 -0700 (PDT) In-Reply-To: <752588A3-C0EF-4844-A0EE-4657CAD40E4C@bsdimp.com> References: <20130709090744.0e497e7e@bender.Home> <32F979BD-FB5C-4111-9586-4C5E7C6DFA71@bsdimp.com> <20130709234837.559e3769@bender.Home> <752588A3-C0EF-4844-A0EE-4657CAD40E4C@bsdimp.com> Date: Wed, 10 Jul 2013 12:26:42 -0700 X-Google-Sender-Auth: HNOZabbbcvtm8BN69lYQs6tz0x4 Message-ID: Subject: Re: Adding a MACHINE_ARCH note From: Adrian Chadd To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 Cc: Baptiste Daroussin , Dimitry Andric , Andrew Turner , 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, 10 Jul 2013 19:26:43 -0000 On 10 July 2013 09:55, Warner Losh wrote: >> That's the reason I replied about it. Not specifically to make it >> happen _everywhere_, but to see if we're about to migrate to a tool >> that doesn't support it, making it a much bigger deal to migrate again >> later. > > I've been talking to Baptiste, and it will support this. Sweet. Thanks! -adrian From owner-freebsd-arch@FreeBSD.ORG Wed Jul 10 19:55: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 752556C5; Wed, 10 Jul 2013 19:55:53 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) by mx1.freebsd.org (Postfix) with ESMTP id ABE421892; Wed, 10 Jul 2013 19:55:52 +0000 (UTC) Received: by mail-wg0-f47.google.com with SMTP id l18so6196817wgh.2 for ; Wed, 10 Jul 2013 12:55:51 -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:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=1yKmgUFE/5BRuz7IGpAy9M2QOY0vl6X/0h7diPjPLvU=; b=S1MPvuIR0GJR3xJEb/KIFhOOna0878iO7i0ZXyzqoe/532NmoAHMyWm7RMzsNNndJ3 0L8iQ+jBxcadb03KEOPLgPjVIzYM1oWDk7N7AkYlkpaupYSVV1s/62m/TAoNXE23opsm CE4NNPYpAcaGA2j88bjU97z4fSqc67ByzCwzl8qO64Y6gPLte9mYVK3dqOzDj1JfuAjT EApoXWLgR8QvBPaBgcREnN7ettHRX9ayQQEWhNqmnlYy+VH5Pq4eVGl9qJLWEjSwwxyx vmvotvBnMbmpj6UySOwF90QAaZi12dznRpQ+3yjl+YRpOrJ6rdvzPhehU337KOUyg8NI 9A4Q== X-Received: by 10.195.12.202 with SMTP id es10mr19359293wjd.17.1373486151695; Wed, 10 Jul 2013 12:55:51 -0700 (PDT) Received: from ithaqua.etoilebsd.net (ithaqua.etoilebsd.net. [37.59.37.188]) by mx.google.com with ESMTPSA id em10sm60045535wid.1.2013.07.10.12.55.50 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 10 Jul 2013 12:55:50 -0700 (PDT) Sender: Baptiste Daroussin Date: Wed, 10 Jul 2013 21:55:47 +0200 From: Baptiste Daroussin To: Adrian Chadd Subject: Re: Adding a MACHINE_ARCH note Message-ID: <20130710195547.GB68830@ithaqua.etoilebsd.net> References: <32F979BD-FB5C-4111-9586-4C5E7C6DFA71@bsdimp.com> <20130709234837.559e3769@bender.Home> <752588A3-C0EF-4844-A0EE-4657CAD40E4C@bsdimp.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="H+4ONPRPur6+Ovig" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Dimitry Andric , Andrew Turner , 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, 10 Jul 2013 19:55:53 -0000 --H+4ONPRPur6+Ovig Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 10, 2013 at 12:26:42PM -0700, Adrian Chadd wrote: > On 10 July 2013 09:55, Warner Losh wrote: >=20 > >> That's the reason I replied about it. Not specifically to make it > >> happen _everywhere_, but to see if we're about to migrate to a tool > >> that doesn't support it, making it a much bigger deal to migrate again > >> later. > > > > I've been talking to Baptiste, and it will support this. >=20 > Sweet. >=20 > Thanks! >=20 >=20 > -adrian Yeah I need to get a simple and uniq way to gather the different ABI, I have been creating my own ABI string to solve this, but I'm far from being a specialist. While thinking about this kind of thing, please please think about a format= that can easily give us a way to figure out a way to get cross ABI binaries supp= ort. pkgng needs for example to allow i386 packages to be installed on amd64 bec= ause amd64 does support it. Maintaining a list the compatibility will be painful. In my own version I have os:version:family:class:... for example here: on FreeBSD 9 i386 we have: freebsd:9:x86:32 on FreeBSD 10 amd64 we have: freebsd:9:x86:64 now if I do want a package I can install on both amd64 and i386 I just have= to create a package saying: freebsd:9:x86 or if I want a package that can be installed on all arches: freebsd:9 It became complicated for arm and mips because of the multiple variation available. the problem with that is that I have to read the binary supported from the binaries themselves which enforce me to get some magical numbers for every arches (which was apparently wrong on arm, thanks Andrew for the fix) Havin= g a note with the direct MACHINE_ARCH will save us complicated code and potenti= al failures with magic numbers. and would be more reliable that getting from uname(3). Just tell me where I can get the right string and how can I check the compa= tible ABI and pkgng will switch to it. I would have love this to happen a year an= d a half before that would have saved me from having to prepare a migration pat= h, but better late that never :) regards, Bapt --H+4ONPRPur6+Ovig Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlHdvEMACgkQ8kTtMUmk6EwdhgCfepn3ygB5bNxzzlF1CwJPndbS 7V8AoKKkJGGdXPGnwT0sjFUUBL15klG+ =Ms7X -----END PGP SIGNATURE----- --H+4ONPRPur6+Ovig-- From owner-freebsd-arch@FreeBSD.ORG Wed Jul 10 20:59: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 52000EF5; Wed, 10 Jul 2013 20:59:42 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) by mx1.freebsd.org (Postfix) with ESMTP id 2E6A21B86; Wed, 10 Jul 2013 20:59:42 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 2A9CFB98A; Wed, 10 Jul 2013 16:59:41 -0400 (EDT) From: John Baldwin To: freebsd-arch@freebsd.org Subject: Re: Adding a MACHINE_ARCH note Date: Wed, 10 Jul 2013 16:11:37 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <32F979BD-FB5C-4111-9586-4C5E7C6DFA71@bsdimp.com> <20130710195547.GB68830@ithaqua.etoilebsd.net> In-Reply-To: <20130710195547.GB68830@ithaqua.etoilebsd.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201307101611.37437.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 10 Jul 2013 16:59:41 -0400 (EDT) Cc: Baptiste Daroussin , Dimitry Andric , Adrian Chadd , Andrew Turner 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, 10 Jul 2013 20:59:42 -0000 On Wednesday, July 10, 2013 3:55:47 pm Baptiste Daroussin wrote: > On Wed, Jul 10, 2013 at 12:26:42PM -0700, Adrian Chadd wrote: > > On 10 July 2013 09:55, Warner Losh wrote: > > > > >> That's the reason I replied about it. Not specifically to make it > > >> happen _everywhere_, but to see if we're about to migrate to a tool > > >> that doesn't support it, making it a much bigger deal to migrate again > > >> later. > > > > > > I've been talking to Baptiste, and it will support this. > > > > Sweet. > > > > Thanks! > > > > > > -adrian > > Yeah I need to get a simple and uniq way to gather the different ABI, I have > been creating my own ABI string to solve this, but I'm far from being a > specialist. > > While thinking about this kind of thing, please please think about a format that > can easily give us a way to figure out a way to get cross ABI binaries support. > > pkgng needs for example to allow i386 packages to be installed on amd64 because > amd64 does support it. > > Maintaining a list the compatibility will be painful. > > In my own version I have > os:version:family:class:... > > for example here: > on FreeBSD 9 i386 we have: > > freebsd:9:x86:32 > > on FreeBSD 10 amd64 we have: > > freebsd:9:x86:64 > > now if I do want a package I can install on both amd64 and i386 I just have to > create a package saying: > > freebsd:9:x86 > > or if I want a package that can be installed on all arches: > > freebsd:9 > > It became complicated for arm and mips because of the multiple variation > available. You should look at how MACHINE_CPUARCH vs MACHINE vs MACHINE_ARCH works. Keep in mind that amd64/i386/pc98 should probably have MACHINE_CPUARCH of x86, but we just haven't done that yet. If we did that I think you could follow src's conventions and be fine. Something like: os:version:cpuarch:arch Where cpuarch == MACHINE_CPUARCH (should be x86 on amd64/i386/pc98, but isn't yet. It ss sane on other platforms) and arch == MACHINE_ARCH (amd64/i386 (for pc98 MACHINE_ARCH is i386)) So that would give: freebsd:9:x86:amd64 freebsd:9:x86:i386 (for both pc98 and i386) freebsd:9:arm:armv6 etc. I think that means we could eventually support x32 as: freebsd:9:x86:x32 We might have an x32 world (but perhaps not a kernel?, though we would need the headers to DTRT) -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Wed Jul 10 21:24: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 D873F5CC for ; Wed, 10 Jul 2013 21:24:07 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ye0-f181.google.com (mail-ye0-f181.google.com [209.85.213.181]) by mx1.freebsd.org (Postfix) with ESMTP id 993531C93 for ; Wed, 10 Jul 2013 21:24:07 +0000 (UTC) Received: by mail-ye0-f181.google.com with SMTP id g12so2569271yee.12 for ; Wed, 10 Jul 2013 14:24:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=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=YT03z4GaXhNrKmRGrCAnDWW5yrg253duTZQ0KDTbrU4=; b=Np+j3OO8uOV/Bk8fjl+u6lDBX3FKyHF7ttxNxDedZKtY73zqfmI11uKIHsZIVb4szK B9zu8cCU2xT5Wr4L2BPAy6B3eo27lZ+7ATG94bwx/k4gBYtu0fUOIxB3KF3NUP0aEq7k 1XRY7v6MR+v7ERo9dmQzH31mIPoWnS7BXTzU/FMPJ/lXYUNIOYO83a4G5ut58pHxIcM8 STFyJr4k+YnwydVANUpSAzCSviwK5/tXSlIwJ1ihpm1+UknVAvm2dM1BzYupQdXAEaZR XjFG2dnj5wUf+6WsoYgNd8xTV5eHZ86iZJlE3XDLfjHu4xemCbW2ynHIiQrbxB4KYyOJ h0pw== X-Received: by 10.236.120.15 with SMTP id o15mr19017926yhh.224.1373488058140; Wed, 10 Jul 2013 13:27:38 -0700 (PDT) Received: from monkey-bot.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPSA id o32sm54911055yhi.5.2013.07.10.13.27.36 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 10 Jul 2013 13:27:37 -0700 (PDT) Sender: Warner Losh Subject: Re: Adding a MACHINE_ARCH note Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20130710195547.GB68830@ithaqua.etoilebsd.net> Date: Wed, 10 Jul 2013 14:27:30 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <2CFD4681-5299-4A7B-A099-758EF30DAB9A@bsdimp.com> References: <32F979BD-FB5C-4111-9586-4C5E7C6DFA71@bsdimp.com> <20130709234837.559e3769@bender.Home> <752588A3-C0EF-4844-A0EE-4657CAD40E4C@bsdimp.com> <20130710195547.GB68830@ithaqua.etoilebsd.net> To: Baptiste Daroussin X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQlpdWJOJ0BsiLQMZdXz7mFVx8U7kmMMxjT3WW6HEqeksZ0ds6b7P0kZFkg0LOs6cr2llzAu Cc: FreeBSD-arch Arch 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, 10 Jul 2013 21:24:07 -0000 On Jul 10, 2013, at 1:55 PM, Baptiste Daroussin wrote: > On Wed, Jul 10, 2013 at 12:26:42PM -0700, Adrian Chadd wrote: >> On 10 July 2013 09:55, Warner Losh wrote: >>=20 >>>> That's the reason I replied about it. Not specifically to make it >>>> happen _everywhere_, but to see if we're about to migrate to a tool >>>> that doesn't support it, making it a much bigger deal to migrate = again >>>> later. >>>=20 >>> I've been talking to Baptiste, and it will support this. >>=20 >> Sweet. >>=20 >> Thanks! >>=20 >>=20 >> -adrian >=20 > Yeah I need to get a simple and uniq way to gather the different ABI, = I have > been creating my own ABI string to solve this, but I'm far from being = a > specialist. uname -p > While thinking about this kind of thing, please please think about a = format that > can easily give us a way to figure out a way to get cross ABI binaries = support. The same way we've always handled it: uname -p > pkgng needs for example to allow i386 packages to be installed on = amd64 because > amd64 does support it. You'll need to maintain a list somewhere. > Maintaining a list the compatibility will be painful. >=20 > In my own version I have > os:version:family:class:... >=20 > for example here: > on FreeBSD 9 i386 we have: >=20 > freebsd:9:x86:32 >=20 > on FreeBSD 10 amd64 we have: >=20 > freebsd:9:x86:64 >=20 > now if I do want a package I can install on both amd64 and i386 I just = have to > create a package saying: >=20 > freebsd:9:x86 >=20 > or if I want a package that can be installed on all arches: >=20 > freebsd:9 The whole x86:64 thing is evil. It should just be uname -p's name. > It became complicated for arm and mips because of the multiple = variation > available. Except there uname -p uniquely defines it (apart from our transition in = current from OABI to EABI on ARM, which was justified as "weird things = happen in -current" :)). > the problem with that is that I have to read the binary supported from = the > binaries themselves which enforce me to get some magical numbers for = every > arches (which was apparently wrong on arm, thanks Andrew for the fix) = Having a > note with the direct MACHINE_ARCH will save us complicated code and = potential > failures with magic numbers. and would be more reliable that getting = from > uname(3). I'm not sure how it would be more reliable. MACHINE_ARCH is uname -p. > Just tell me where I can get the right string and how can I check the = compatible > ABI and pkgng will switch to it. I would have love this to happen a = year and a > half before that would have saved me from having to prepare a = migration path, > but better late that never :) uname -p is the first cut. It is intended to completely describe the = main ABI of the current machine. However, you're right. The kernel should export a list of ABIs that it = supports. We don't currently do that. I'd propose hw.abi that will export the ABIs the kernel supports. This = way you won't install i386 binaries on an AMD64 system that doesn't have = COMPAT_FREEBSD32 in it. But that might get more interesting, since there = are some ABIs we support that aren't uname -p. These are things like = SVR4, AOUT (on i386), and various flavors of Linux. These ABIs are = likely beyond the scope of pngng, but maybe linux isn't :) Anyway, I'll work up a patch to give you what you need, and some shell = code for what to do when it doesn't exist. Warner= From owner-freebsd-arch@FreeBSD.ORG Wed Jul 10 21:24: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 329FD676; Wed, 10 Jul 2013 21:24:41 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) by mx1.freebsd.org (Postfix) with ESMTP id 476341C9A; Wed, 10 Jul 2013 21:24:40 +0000 (UTC) Received: by mail-wi0-f182.google.com with SMTP id m6so6830006wiv.3 for ; Wed, 10 Jul 2013 14:24:39 -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:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=12zswVVyoN3nIW0aINUJzq3CYnB7ywsTeBJgK5j5u7U=; b=SDnDgdws5mvA7IR8MPER2IQapF/s+yT0yB+yPw76mRVxDdwCF3q9oCS6FFz7lgNnGb lLBkw7D/NSbX/riyIYtXhCK0TkiHAvlobw9+2lLbGOa1r+2USlpvhNLVlVZHcM4B1gEt SKalORCunfd9h/WRzRxV5fV8QL1wRpwPKxHy2O3xxeUlGr+D4k4k8J39QPv7+Xv3pyYf OQI0ldLFE0Ut/yoNIEZrSj1gDDdVPNoQPRtqjq8PpF1/S+MIpSeR/F/DLMgaccxjp4iy /1H8JD03xK78f1/tH8OEjmJRJL7fI28v2THNkgAW3k/bif+UkpgLzXejlIA7Xy/9lVmx hHyg== X-Received: by 10.194.22.41 with SMTP id a9mr18482490wjf.16.1373491479408; Wed, 10 Jul 2013 14:24:39 -0700 (PDT) Received: from ithaqua.etoilebsd.net (ithaqua.etoilebsd.net. [37.59.37.188]) by mx.google.com with ESMTPSA id a6sm21584425wib.10.2013.07.10.14.24.37 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 10 Jul 2013 14:24:38 -0700 (PDT) Sender: Baptiste Daroussin Date: Wed, 10 Jul 2013 23:24:36 +0200 From: Baptiste Daroussin To: John Baldwin Subject: Re: Adding a MACHINE_ARCH note Message-ID: <20130710212436.GF68830@ithaqua.etoilebsd.net> References: <32F979BD-FB5C-4111-9586-4C5E7C6DFA71@bsdimp.com> <20130710195547.GB68830@ithaqua.etoilebsd.net> <201307101611.37437.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="RE3pQJLXZi4fr8Xo" Content-Disposition: inline In-Reply-To: <201307101611.37437.jhb@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Adrian Chadd , Dimitry Andric , Andrew Turner , 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, 10 Jul 2013 21:24:41 -0000 --RE3pQJLXZi4fr8Xo Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 10, 2013 at 04:11:37PM -0400, John Baldwin wrote: > On Wednesday, July 10, 2013 3:55:47 pm Baptiste Daroussin wrote: > > On Wed, Jul 10, 2013 at 12:26:42PM -0700, Adrian Chadd wrote: > > > On 10 July 2013 09:55, Warner Losh wrote: > > >=20 > > > >> That's the reason I replied about it. Not specifically to make it > > > >> happen _everywhere_, but to see if we're about to migrate to a tool > > > >> that doesn't support it, making it a much bigger deal to migrate a= gain > > > >> later. > > > > > > > > I've been talking to Baptiste, and it will support this. > > >=20 > > > Sweet. > > >=20 > > > Thanks! > > >=20 > > >=20 > > > -adrian > >=20 > > Yeah I need to get a simple and uniq way to gather the different ABI, I= have > > been creating my own ABI string to solve this, but I'm far from being a > > specialist. > >=20 > > While thinking about this kind of thing, please please think about a fo= rmat that > > can easily give us a way to figure out a way to get cross ABI binaries = support. > >=20 > > pkgng needs for example to allow i386 packages to be installed on amd64= because > > amd64 does support it. > >=20 > > Maintaining a list the compatibility will be painful. > >=20 > > In my own version I have > > os:version:family:class:... > >=20 > > for example here: > > on FreeBSD 9 i386 we have: > >=20 > > freebsd:9:x86:32 > >=20 > > on FreeBSD 10 amd64 we have: > >=20 > > freebsd:9:x86:64 > >=20 > > now if I do want a package I can install on both amd64 and i386 I just = have to > > create a package saying: > >=20 > > freebsd:9:x86 > >=20 > > or if I want a package that can be installed on all arches: > >=20 > > freebsd:9 > >=20 > > It became complicated for arm and mips because of the multiple variation > > available. >=20 > You should look at how MACHINE_CPUARCH vs MACHINE vs MACHINE_ARCH works. >=20 > Keep in mind that amd64/i386/pc98 should probably have MACHINE_CPUARCH of= x86, > but we just haven't done that yet. If we did that I think you could foll= ow > src's conventions and be fine. Something like: >=20 > os:version:cpuarch:arch >=20 > Where cpuarch =3D=3D MACHINE_CPUARCH (should be x86 on amd64/i386/pc98, b= ut isn't > yet. It ss sane on other platforms) and > arch =3D=3D MACHINE_ARCH (amd64/i386 (for pc98 MACHINE_ARCH is i386)) >=20 > So that would give: >=20 > freebsd:9:x86:amd64 > freebsd:9:x86:i386 (for both pc98 and i386) > freebsd:9:arm:armv6 >=20 > etc. >=20 > I think that means we could eventually support x32 as: >=20 > freebsd:9:x86:x32 >=20 > We might have an x32 world (but perhaps not a kernel?, though we would ne= ed > the headers to DTRT) I do like the idea a lot. regards, Bapt --RE3pQJLXZi4fr8Xo Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlHd0RMACgkQ8kTtMUmk6EzoRgCfQAG2PpGMrHuR1/7oxcpt9m69 T94AoKfsXS0TGKh9MfwD8fCYIGT8m6LG =ALBN -----END PGP SIGNATURE----- --RE3pQJLXZi4fr8Xo-- From owner-freebsd-arch@FreeBSD.ORG Wed Jul 10 21:27: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 7E96C73C for ; Wed, 10 Jul 2013 21:27:22 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-f178.google.com (mail-ie0-f178.google.com [209.85.223.178]) by mx1.freebsd.org (Postfix) with ESMTP id 4EC651CAF for ; Wed, 10 Jul 2013 21:27:22 +0000 (UTC) Received: by mail-ie0-f178.google.com with SMTP id u16so16478457iet.37 for ; Wed, 10 Jul 2013 14:27:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=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=vhKLjA8cQjgqrT2Moi6+Zv/8gxMujrXSoUBUz7GVdok=; b=jgRn5OZGk0xD01Xdf83CdQCw2Z+w70suOP4bTh78mQGX7FwhihcoPyigrgjFUqUroV F8D0Df6mfcFpWhx5tmkzng9gVzTG2NKwV9Vcvci5rDMcekmKLKU4IunDNKK0TdpBt8Ld nJ3mIgKiap7hKAtzTEyB3EglmXtXnDadWsdTaKjh/uvcvuOXOE3XsDSro9yuiRuVRcGy jWRuwIRrKUniSI+LTEHyREw6akm/vYq137/Ydat98g6tkoBgFCImqMaZZsPaKZ+th+j3 axoY7R4yLngTv7HQyy0FGfn4a6dbH0rrHJLY2JFC/Nm3c3OwfYkLsPgBJlZbP1xQBx8A EQ4w== X-Received: by 10.50.18.81 with SMTP id u17mr12419766igd.8.1373491636449; Wed, 10 Jul 2013 14:27:16 -0700 (PDT) Received: from monkey-bot.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPSA id x10sm38104798igl.3.2013.07.10.14.27.14 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 10 Jul 2013 14:27:15 -0700 (PDT) Sender: Warner Losh Subject: Re: Adding a MACHINE_ARCH note Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20130710212436.GF68830@ithaqua.etoilebsd.net> Date: Wed, 10 Jul 2013 15:27:12 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <32F979BD-FB5C-4111-9586-4C5E7C6DFA71@bsdimp.com> <20130710195547.GB68830@ithaqua.etoilebsd.net> <201307101611.37437.jhb@freebsd.org> <20130710212436.GF68830@ithaqua.etoilebsd.net> To: Baptiste Daroussin X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQnccryUJivAsInqz+QpU8bwmmwmRK0oVgpKcU7uZ5MqKJ/t2f8OI4WdLod7hYbOOdrEcQQX Cc: Adrian Chadd , Dimitry Andric , Andrew Turner , 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, 10 Jul 2013 21:27:22 -0000 On Jul 10, 2013, at 3:24 PM, Baptiste Daroussin wrote: > On Wed, Jul 10, 2013 at 04:11:37PM -0400, John Baldwin wrote: >> On Wednesday, July 10, 2013 3:55:47 pm Baptiste Daroussin wrote: >>> On Wed, Jul 10, 2013 at 12:26:42PM -0700, Adrian Chadd wrote: >>>> On 10 July 2013 09:55, Warner Losh wrote: >>>>=20 >>>>>> That's the reason I replied about it. Not specifically to make it >>>>>> happen _everywhere_, but to see if we're about to migrate to a = tool >>>>>> that doesn't support it, making it a much bigger deal to migrate = again >>>>>> later. >>>>>=20 >>>>> I've been talking to Baptiste, and it will support this. >>>>=20 >>>> Sweet. >>>>=20 >>>> Thanks! >>>>=20 >>>>=20 >>>> -adrian >>>=20 >>> Yeah I need to get a simple and uniq way to gather the different = ABI, I have >>> been creating my own ABI string to solve this, but I'm far from = being a >>> specialist. >>>=20 >>> While thinking about this kind of thing, please please think about a = format that >>> can easily give us a way to figure out a way to get cross ABI = binaries support. >>>=20 >>> pkgng needs for example to allow i386 packages to be installed on = amd64 because >>> amd64 does support it. >>>=20 >>> Maintaining a list the compatibility will be painful. >>>=20 >>> In my own version I have >>> os:version:family:class:... >>>=20 >>> for example here: >>> on FreeBSD 9 i386 we have: >>>=20 >>> freebsd:9:x86:32 >>>=20 >>> on FreeBSD 10 amd64 we have: >>>=20 >>> freebsd:9:x86:64 >>>=20 >>> now if I do want a package I can install on both amd64 and i386 I = just have to >>> create a package saying: >>>=20 >>> freebsd:9:x86 >>>=20 >>> or if I want a package that can be installed on all arches: >>>=20 >>> freebsd:9 >>>=20 >>> It became complicated for arm and mips because of the multiple = variation >>> available. >>=20 >> You should look at how MACHINE_CPUARCH vs MACHINE vs MACHINE_ARCH = works. >>=20 >> Keep in mind that amd64/i386/pc98 should probably have = MACHINE_CPUARCH of x86, >> but we just haven't done that yet. If we did that I think you could = follow >> src's conventions and be fine. Something like: >>=20 >> os:version:cpuarch:arch >>=20 >> Where cpuarch =3D=3D MACHINE_CPUARCH (should be x86 on = amd64/i386/pc98, but isn't >> yet. It ss sane on other platforms) and >> arch =3D=3D MACHINE_ARCH (amd64/i386 (for pc98 MACHINE_ARCH is i386)) >>=20 >> So that would give: >>=20 >> freebsd:9:x86:amd64 >> freebsd:9:x86:i386 (for both pc98 and i386) >> freebsd:9:arm:armv6 >>=20 >> etc. >>=20 >> I think that means we could eventually support x32 as: >>=20 >> freebsd:9:x86:x32 >>=20 >> We might have an x32 world (but perhaps not a kernel?, though we = would need >> the headers to DTRT) >=20 > I do like the idea a lot. We should add a flag to uname to get MACHINE_CPUARCH, and publish it as = hw.cpu_arch in sysctl. Warner From owner-freebsd-arch@FreeBSD.ORG Wed Jul 10 21:31:20 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 59CB499B; Wed, 10 Jul 2013 21:31:20 +0000 (UTC) (envelope-from baptiste.daroussin@gmail.com) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) by mx1.freebsd.org (Postfix) with ESMTP id 9320F1CDC; Wed, 10 Jul 2013 21:31:19 +0000 (UTC) Received: by mail-wi0-f182.google.com with SMTP id m6so6835489wiv.3 for ; Wed, 10 Jul 2013 14:31:18 -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:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=AirHhlDCmmIBli0td0pHGeL9kw8YEqLtGZ3S9UhMt9I=; b=eK8gjHU4nPV34fQNwaHOI7nIxMpTaorssXS8O64T+vYFpYehs3Y6Y1wxqcPHCbg9gw PntiLTYB2FC6w1fF7GGTtbE+QTF5dT57muV6h18XtRK8JM1cERxfaFa9fLlH21fO8lrQ 5mUZS7OQlY5a5PH2EXt7fJ3Nhm/E/PCuem+vhLPxJpV57HA8KN1wht762WVapBa7WHFq jHKeR3Q3ZRKW+Abcst9ywlbrkRV8Ly2NQAkWH8hhRCuJDFoDbHX2L52fD1FPIVZaJcYW PDk7ZIRf3K8CqSDDM7qEEAuwIb9W9bz8ZmrfRdGPNOWkwaH/R67EV5nZ+A68lWscxopY HAKw== X-Received: by 10.194.240.169 with SMTP id wb9mr18574613wjc.90.1373491878781; Wed, 10 Jul 2013 14:31:18 -0700 (PDT) Received: from ithaqua.etoilebsd.net (ithaqua.etoilebsd.net. [37.59.37.188]) by mx.google.com with ESMTPSA id eu1sm69761484wib.8.2013.07.10.14.31.17 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 10 Jul 2013 14:31:17 -0700 (PDT) Sender: Baptiste Daroussin Date: Wed, 10 Jul 2013 23:31:15 +0200 From: Baptiste Daroussin To: Warner Losh Subject: Re: Adding a MACHINE_ARCH note Message-ID: <20130710213115.GG68830@ithaqua.etoilebsd.net> References: <32F979BD-FB5C-4111-9586-4C5E7C6DFA71@bsdimp.com> <20130710195547.GB68830@ithaqua.etoilebsd.net> <201307101611.37437.jhb@freebsd.org> <20130710212436.GF68830@ithaqua.etoilebsd.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xs+9IvWevLaxKUtW" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Adrian Chadd , Dimitry Andric , Andrew Turner , 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, 10 Jul 2013 21:31:20 -0000 --xs+9IvWevLaxKUtW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 10, 2013 at 03:27:12PM -0600, Warner Losh wrote: >=20 > On Jul 10, 2013, at 3:24 PM, Baptiste Daroussin wrote: >=20 > > On Wed, Jul 10, 2013 at 04:11:37PM -0400, John Baldwin wrote: > >> On Wednesday, July 10, 2013 3:55:47 pm Baptiste Daroussin wrote: > >>> On Wed, Jul 10, 2013 at 12:26:42PM -0700, Adrian Chadd wrote: > >>>> On 10 July 2013 09:55, Warner Losh wrote: > >>>>=20 > >>>>>> That's the reason I replied about it. Not specifically to make it > >>>>>> happen _everywhere_, but to see if we're about to migrate to a tool > >>>>>> that doesn't support it, making it a much bigger deal to migrate a= gain > >>>>>> later. > >>>>>=20 > >>>>> I've been talking to Baptiste, and it will support this. > >>>>=20 > >>>> Sweet. > >>>>=20 > >>>> Thanks! > >>>>=20 > >>>>=20 > >>>> -adrian > >>>=20 > >>> Yeah I need to get a simple and uniq way to gather the different ABI,= I have > >>> been creating my own ABI string to solve this, but I'm far from being= a > >>> specialist. > >>>=20 > >>> While thinking about this kind of thing, please please think about a = format that > >>> can easily give us a way to figure out a way to get cross ABI binarie= s support. > >>>=20 > >>> pkgng needs for example to allow i386 packages to be installed on amd= 64 because > >>> amd64 does support it. > >>>=20 > >>> Maintaining a list the compatibility will be painful. > >>>=20 > >>> In my own version I have > >>> os:version:family:class:... > >>>=20 > >>> for example here: > >>> on FreeBSD 9 i386 we have: > >>>=20 > >>> freebsd:9:x86:32 > >>>=20 > >>> on FreeBSD 10 amd64 we have: > >>>=20 > >>> freebsd:9:x86:64 > >>>=20 > >>> now if I do want a package I can install on both amd64 and i386 I jus= t have to > >>> create a package saying: > >>>=20 > >>> freebsd:9:x86 > >>>=20 > >>> or if I want a package that can be installed on all arches: > >>>=20 > >>> freebsd:9 > >>>=20 > >>> It became complicated for arm and mips because of the multiple variat= ion > >>> available. > >>=20 > >> You should look at how MACHINE_CPUARCH vs MACHINE vs MACHINE_ARCH work= s. > >>=20 > >> Keep in mind that amd64/i386/pc98 should probably have MACHINE_CPUARCH= of x86, > >> but we just haven't done that yet. If we did that I think you could f= ollow > >> src's conventions and be fine. Something like: > >>=20 > >> os:version:cpuarch:arch > >>=20 > >> Where cpuarch =3D=3D MACHINE_CPUARCH (should be x86 on amd64/i386/pc98= , but isn't > >> yet. It ss sane on other platforms) and > >> arch =3D=3D MACHINE_ARCH (amd64/i386 (for pc98 MACHINE_ARCH is i386)) > >>=20 > >> So that would give: > >>=20 > >> freebsd:9:x86:amd64 > >> freebsd:9:x86:i386 (for both pc98 and i386) > >> freebsd:9:arm:armv6 > >>=20 > >> etc. > >>=20 > >> I think that means we could eventually support x32 as: > >>=20 > >> freebsd:9:x86:x32 > >>=20 > >> We might have an x32 world (but perhaps not a kernel?, though we would= need > >> the headers to DTRT) > >=20 > > I do like the idea a lot. >=20 > We should add a flag to uname to get MACHINE_CPUARCH, and publish it as h= w.cpu_arch in sysctl. >=20 I will still have to workaround on older releases. The one without those informations. regards, Bapt --xs+9IvWevLaxKUtW Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlHd0qMACgkQ8kTtMUmk6Ewo2gCgp6savr1WldJnX7bdfIFEzZmk iXsAnio+PbjWd2JlRVxIXtGnIYynxOGQ =ShTv -----END PGP SIGNATURE----- --xs+9IvWevLaxKUtW-- From owner-freebsd-arch@FreeBSD.ORG Wed Jul 10 22:19:44 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 D067496A for ; Wed, 10 Jul 2013 22:19:44 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from mail.icecube.wisc.edu (trout.icecube.wisc.edu [128.104.255.119]) by mx1.freebsd.org (Postfix) with ESMTP id 9B47E1EC5 for ; Wed, 10 Jul 2013 22:19:44 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.icecube.wisc.edu (Postfix) with ESMTP id 826CA58380 for ; Wed, 10 Jul 2013 16:51:03 -0500 (CDT) X-Virus-Scanned: amavisd-new at icecube.wisc.edu Received: from mail.icecube.wisc.edu ([127.0.0.1]) by localhost (trout.icecube.wisc.edu [127.0.0.1]) (amavisd-new, port 10030) with ESMTP id ZPL1JzRiXLii for ; Wed, 10 Jul 2013 16:51:03 -0500 (CDT) Received: from terminus.icecube.wisc.edu (terminus.icecube.wisc.edu [172.16.223.97]) by mail.icecube.wisc.edu (Postfix) with ESMTP id 6359D5837F for ; Wed, 10 Jul 2013 16:51:03 -0500 (CDT) Message-ID: <51DDD747.80206@freebsd.org> Date: Wed, 10 Jul 2013 16:51:03 -0500 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130627 Thunderbird/17.0.7 MIME-Version: 1.0 To: freebsd-arch@freebsd.org Subject: Re: Adding a MACHINE_ARCH note References: <32F979BD-FB5C-4111-9586-4C5E7C6DFA71@bsdimp.com> <20130710195547.GB68830@ithaqua.etoilebsd.net> <201307101611.37437.jhb@freebsd.org> <20130710212436.GF68830@ithaqua.etoilebsd.net> <20130710213115.GG68830@ithaqua.etoilebsd.net> In-Reply-To: <20130710213115.GG68830@ithaqua.etoilebsd.net> 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: Wed, 10 Jul 2013 22:19:44 -0000 On 07/10/13 16:31, Baptiste Daroussin wrote: > On Wed, Jul 10, 2013 at 03:27:12PM -0600, Warner Losh wrote: >> On Jul 10, 2013, at 3:24 PM, Baptiste Daroussin wrote: >> >>> >>> You should look at how MACHINE_CPUARCH vs MACHINE vs MACHINE_ARCH works. >>> >>> Keep in mind that amd64/i386/pc98 should probably have MACHINE_CPUARCH of x86, >>> but we just haven't done that yet. If we did that I think you could follow >>> src's conventions and be fine. Something like: >>> >>> os:version:cpuarch:arch >>> >>> Where cpuarch == MACHINE_CPUARCH (should be x86 on amd64/i386/pc98, but isn't >>> yet. It ss sane on other platforms) and >>> arch == MACHINE_ARCH (amd64/i386 (for pc98 MACHINE_ARCH is i386)) >>> >>> So that would give: >>> >>> freebsd:9:x86:amd64 >>> freebsd:9:x86:i386 (for both pc98 and i386) >>> freebsd:9:arm:armv6 >>> >>> etc. >>> >>> I think that means we could eventually support x32 as: >>> >>> freebsd:9:x86:x32 >>> >>> We might have an x32 world (but perhaps not a kernel?, though we would need >>> the headers to DTRT) >>> I do like the idea a lot. >> We should add a flag to uname to get MACHINE_CPUARCH, and publish it as hw.cpu_arch in sysctl. >> > I will still have to workaround on older releases. The one without those > informations. > > regards, > Bapt On those systems, I think you can easily get away with assuming hw.abi == `uname -p`. Installing i386 packages on amd64 systems (or powerpc on powerpc64 or ...) will likely require some infrastructure work anyway and hw.abi is a perfect quick MFC candidate. A few quick special cases will solve any remaining problems almost universally. -Nathan From owner-freebsd-arch@FreeBSD.ORG Thu Jul 11 04:03:42 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 E934AF4D; Thu, 11 Jul 2013 04:03:42 +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 AB54C1EAF; Thu, 11 Jul 2013 04:03:42 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r6B43XRs057972; Thu, 11 Jul 2013 04:03:33 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.123] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id pmvve2nmpsaxxzub773att86n6; Thu, 11 Jul 2013 04:03:33 +0000 (UTC) (envelope-from tim@kientzle.com) Subject: Re: Adding a MACHINE_ARCH note Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: <2CFD4681-5299-4A7B-A099-758EF30DAB9A@bsdimp.com> Date: Wed, 10 Jul 2013 21:03:31 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <32F979BD-FB5C-4111-9586-4C5E7C6DFA71@bsdimp.com> <20130709234837.559e3769@bender.Home> <752588A3-C0EF-4844-A0EE-4657CAD40E4C@bsdimp.com> <20130710195547.GB68830@ithaqua.etoilebsd.net> <2CFD4681-5299-4A7B-A099-758EF30DAB9A@bsdimp.com> To: Warner Losh X-Mailer: Apple Mail (2.1283) Cc: Baptiste Daroussin , FreeBSD-arch Arch 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, 11 Jul 2013 04:03:43 -0000 On Jul 10, 2013, at 1:27 PM, Warner Losh wrote: > On Jul 10, 2013, at 1:55 PM, Baptiste Daroussin wrote: >=20 >> Just tell me where I can get the right string and how can I check the = compatible >> ABI and pkgng will switch to it. I would have love this to happen a = year and a >> half before that would have saved me from having to prepare a = migration path, >> but better late that never :) >=20 > uname -p is the first cut. It is intended to completely describe the = main ABI of the current machine. >=20 > However, you're right. The kernel should export a list of ABIs that it = supports. We don't currently do that. >=20 > I'd propose hw.abi that will export the ABIs the kernel supports.=20 How does this work in the case where I'm building an armv6 image on an i386 system? Or doing package installs directly on my NFS server, which isn't the same architecture as the diskless systems running from it? For that matter, just querying the kernel would give wrong results for an i386 jail running on amd64, where the kernel might support amd64 but 64-bit libraries aren't available. In all of these cases, it's the ABI of the target system that matters, and there's no running kernel to query. This is why pkgng today looks at ELF information in /bin/sh to determine what is supported by the target system. How can we code information equivalent to uname -p in a place where it can be statically determined from an image of a non-running system? Tim From owner-freebsd-arch@FreeBSD.ORG Thu Jul 11 04:25: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 023CF478 for ; Thu, 11 Jul 2013 04:25:44 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-f180.google.com (mail-ie0-f180.google.com [209.85.223.180]) by mx1.freebsd.org (Postfix) with ESMTP id C31F41F5A for ; Thu, 11 Jul 2013 04:25:42 +0000 (UTC) Received: by mail-ie0-f180.google.com with SMTP id f4so16979013iea.11 for ; Wed, 10 Jul 2013 21:25:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=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=vohFR26xUoWI4EpjPrvZeB4RiqyTk/CE9/oOechRSd0=; b=DlrwxagIeE/R/wHOOboSqByOPbw5zNp3yftiE0cPhAMu8lttp+utZX8MBv4K/kaYHI lgh/yfblOrJwoyPISS97gPHjWpUled26Mrucf+CcBjKkERoQzrWawo1LPg3qg9LecLVW uI7e/4bgnWLee5q/LnEsBdkE2VRIBU7CC69UrsGyE+J2d/VkAu7Vmb+6g/2kDye6pBfv HOFVDPHTjl+Je5CfQtNpzyCrHMmrJcg+pBODM+akhF8LPACksbWplROh7FcI5Fd9rbUe lY4iAk4DDd7Re8ubd+gqpP9Tm10H+kvb2hAD4W8rDD23eXn9QuFV5S4BC8A3s7vxVtUL 1qCQ== X-Received: by 10.50.129.38 with SMTP id nt6mr10684394igb.16.1373516742455; Wed, 10 Jul 2013 21:25:42 -0700 (PDT) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id jg5sm38614308igb.0.2013.07.10.21.25.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 10 Jul 2013 21:25:41 -0700 (PDT) Sender: Warner Losh Subject: Re: Adding a MACHINE_ARCH note Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Wed, 10 Jul 2013 22:25:39 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <32F979BD-FB5C-4111-9586-4C5E7C6DFA71@bsdimp.com> <20130709234837.559e3769@bender.Home> <752588A3-C0EF-4844-A0EE-4657CAD40E4C@bsdimp.com> <20130710195547.GB68830@ithaqua.etoilebsd.net> <2CFD4681-5299-4A7B-A099-758EF30DAB9A@bsdimp.com> To: Tim Kientzle X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQnbF8Ixqf9TJga8jYtpkOjgGSUKHgoP6Th/BqbYdtz4Xpy/ygpN47sC8Y3Q1a7C1PPf+v52 Cc: Baptiste Daroussin , FreeBSD-arch Arch 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, 11 Jul 2013 04:25:44 -0000 On Jul 10, 2013, at 10:03 PM, Tim Kientzle wrote: > On Jul 10, 2013, at 1:27 PM, Warner Losh wrote: >=20 >> On Jul 10, 2013, at 1:55 PM, Baptiste Daroussin wrote: >>=20 >>> Just tell me where I can get the right string and how can I check = the compatible >>> ABI and pkgng will switch to it. I would have love this to happen a = year and a >>> half before that would have saved me from having to prepare a = migration path, >>> but better late that never :) >>=20 >> uname -p is the first cut. It is intended to completely describe the = main ABI of the current machine. >>=20 >> However, you're right. The kernel should export a list of ABIs that = it supports. We don't currently do that. >>=20 >> I'd propose hw.abi that will export the ABIs the kernel supports.=20 >=20 > How does this work in the case where I'm building an armv6 image > on an i386 system? Or doing package installs directly on my NFS > server, which isn't the same architecture as the diskless systems > running from it? For that matter, just querying the kernel would > give wrong results for an i386 jail running on amd64, where the > kernel might support amd64 but 64-bit libraries aren't available. Sounds like a good number of cases for an override flag. > In all of these cases, it's the ABI of the target system that matters, > and there's no running kernel to query. Usually you have a kernel to query. When you don't, the user will have = to tell the pkg tools what to use. > This is why pkgng today looks at ELF information in /bin/sh to > determine what is supported by the target system. But that's still not right, since it will only allow you to install one = ABI. It would be impossible to install i386 packages on an amd64 = machine, so I'm not sure this is a winning argument. > How can we code information equivalent to uname -p in > a place where it can be statically determined from an image > of a non-running system? I would wager that most of the time, uname -p is what you want. Since = you are trying to second guess what's going on, while still allowing for = a wider variety of things, we'd need to have some automatic way of = determining what's supported, but also some way to override it. Most of the time, pkgng is used by a user installing packages on the = system he or she will be running on. We should optimize that path, while = still allowing others to work with an override flag. Much like we = default to the current running system in buildworld, unless you = override, and we don' t allow you to install on a system where = TARGET_ARCH !=3D MACHINE_ARCH unless you specify an override. Warner= From owner-freebsd-arch@FreeBSD.ORG Thu Jul 11 06:10:06 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id F36A727F; Thu, 11 Jul 2013 06:10:05 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-ee0-x232.google.com (mail-ee0-x232.google.com [IPv6:2a00:1450:4013:c00::232]) by mx1.freebsd.org (Postfix) with ESMTP id 6491E12CC; Thu, 11 Jul 2013 06:10:05 +0000 (UTC) Received: by mail-ee0-f50.google.com with SMTP id d49so5342092eek.9 for ; Wed, 10 Jul 2013 23:10:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=TI9w8VPqk5PoSW/HItBeqQG9r0r7L4COQyYO5zXTH2w=; b=VMMg9gXe9HGsJoJtPFNuLqLdVomxC/Ig9/JjFt3NPyzVVTbmLfKFbe9kzdwFA3rMX3 PJRr1tNl7kjd3gByHUlZ/EGiynraBe6Vx+dz0nKz95aYhCO7rn0kyQF7vsF60SpofjWd Pg4c66ZwaA15/CVU8AXlms3M1t3oaG/tRsLsAW3SkQCdpteYSX2Ny90Jg5ii1aEcBMY3 Dhc0IlIb7eSO/Dkby6j6OfZPdoPN29ZVJvXLaDJkJ1tFaCnh182A5mTQjnVjtJc/Vv30 aRcpXigxQFC+JyjVeu8uf6fR3T+kI2zVnH7eA0cK3KJ2QOE/Cl/cBmwWeVbyEsbc2KgC /ckg== X-Received: by 10.15.36.133 with SMTP id i5mr40161739eev.52.1373522997647; Wed, 10 Jul 2013 23:09:57 -0700 (PDT) Received: from localhost ([188.230.122.226]) by mx.google.com with ESMTPSA id n5sm66204723eed.9.2013.07.10.23.09.55 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 10 Jul 2013 23:09:56 -0700 (PDT) Date: Thu, 11 Jul 2013 09:09:54 +0300 From: Mikolaj Golub To: Jilles Tjoelker Subject: Re: ABI change in libkvm (kvm_uread removal) Message-ID: <20130711060953.GA64536@gmail.com> References: <20130709185846.GA19508@gmail.com> <20130709211657.GA86400@stack.nl> <20130710063406.GA39842@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130710063406.GA39842@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-arch@freebsd.org, Robert Millan 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, 11 Jul 2013 06:10:06 -0000 On Wed, Jul 10, 2013 at 09:34:08AM +0300, Mikolaj Golub wrote: > Thank you all for your suggestions. I like Jilles' the most. So I am > going to return kvm_uread back to stable/9 by a direct commit and > remove it entirely from head and bump soname. > Done (r253166, r253167). Thanks. -- Mikolaj Golub From owner-freebsd-arch@FreeBSD.ORG Thu Jul 11 08:42: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 0C8D1912; Thu, 11 Jul 2013 08:42:20 +0000 (UTC) (envelope-from rmh.aybabtu@gmail.com) Received: from mail-qe0-x22b.google.com (mail-qe0-x22b.google.com [IPv6:2607:f8b0:400d:c02::22b]) by mx1.freebsd.org (Postfix) with ESMTP id 9DB221B1F; Thu, 11 Jul 2013 08:42:19 +0000 (UTC) Received: by mail-qe0-f43.google.com with SMTP id q19so4247331qeb.2 for ; Thu, 11 Jul 2013 01:42:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=4qfUd16ti8WbFOJNOAfCCVLjFU6aSx3lZqrhRy9gzxk=; b=lpT8zfDvdqn/pBo9awAn7YE4C0bqKdxOZ3W+Ef54cZXOXQ2N3m9KYtJY7J8F2BZNzU oIsv04ioNWGAWKLLGbwwkeU259HQNMLU7yUuKch9OswrJNCyhCs3PBFVM/rco0QVo6c7 N7pQL0PaYfFJLjYhxAilEZyDqSMG9t+tq+xGELFWEwwe5hEIgQtkBQXgTcpjPkxDnPio 9BOoUm2D7AWmb6HYqVOk+auXKOHq/TwigMGo/J9iP2v1dAH1XPPBkgIdTh2SPUNPXbqG jEEb2ENYj3unSKFHnyrib1GF/0owM6js4r4NH0jaxx8roR6YRM0XzrvRyuQ2Hjm5FU6E oeyQ== MIME-Version: 1.0 X-Received: by 10.224.63.7 with SMTP id z7mr32534457qah.51.1373532138876; Thu, 11 Jul 2013 01:42:18 -0700 (PDT) Sender: rmh.aybabtu@gmail.com Received: by 10.49.26.193 with HTTP; Thu, 11 Jul 2013 01:42:18 -0700 (PDT) In-Reply-To: References: <20130709113553.GP67810@FreeBSD.org> <20130709165939.GP91021@kib.kiev.ua> <0657575A-BF3A-486F-9582-C01E0FD97E38@bsdimp.com> <51DC4712.20707@coosemans.org> <6E057FD0-9054-44CD-A806-3AFD8A7196CC@bsdimp.com> Date: Thu, 11 Jul 2013 10:42:18 +0200 X-Google-Sender-Auth: E063lD7OPU_ne8wGHLQ77CB7RT0 Message-ID: Subject: Re: libutil in Debian From: Robert Millan To: Justin Hibbits Content-Type: text/plain; charset=UTF-8 Cc: Konstantin Belousov , Tijl Coosemans , Gleb Smirnoff , 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, 11 Jul 2013 08:42:20 -0000 2013/7/9 Justin Hibbits : > I was thinking more in terms of adding the functions to the debian local > patch set. I don't know how intrusive it would be, but it may be worth > looking into. You may not believe this, but it is even worse. Can you believe they even refused to add trivial syscall stubs, such as nlm_syscall()? They say this "belongs elsewhere" even though it's -lc in FreeBSD like most (all?) syscall stubs. Look at the kind of workarounds we have to endure: http://anonscm.debian.org/viewvc/glibc-bsd/trunk/freebsd-utils/debian/patches/036_nfs_glibc.diff?revision=4047&view=markup Heck, even the trivial update to , which was *already* of BSD origin since ancient times, was restricted to only apply on our port, so that the new macros (e.g. LIST_FOREACH_SAFE) were not available on Debian GNU/Linux. I'm sorry, I really appreciate your intent but I think there's zero chance of this working through Debian patchset to Glibc. -- Robert Millan From owner-freebsd-arch@FreeBSD.ORG Thu Jul 11 11:55: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 65A28E87 for ; Thu, 11 Jul 2013 11:55:47 +0000 (UTC) (envelope-from rmh.aybabtu@gmail.com) Received: from mail-qe0-x22c.google.com (mail-qe0-x22c.google.com [IPv6:2607:f8b0:400d:c02::22c]) by mx1.freebsd.org (Postfix) with ESMTP id 2F8251735 for ; Thu, 11 Jul 2013 11:55:47 +0000 (UTC) Received: by mail-qe0-f44.google.com with SMTP id 5so4370405qeb.31 for ; Thu, 11 Jul 2013 04:55:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=8UVXdMSnFAVtYBoUj8Usa+BhYq5bNvGIKnwdxDSgNOI=; b=j5kPJS3YDiIFmNJusp2T+BHInJCBLxjII4+u6/mwMD08T1zueS1E/PI8ZY6HTqlmZK UfuNR5MqmKcnkSk3AwDFix8glnKzQ8ieqQ1XS8hWvn7U77htgIiSw2bWk9MirRTBdipp vUaLIRd1DIe0/B+XFZ1l8M0EymkrLr3J+/TkgYhkBxJZI5RlJxWIY4bjjNAtvi/LtHpz 4+BK6HeL41wYaayVt2Uxfeo7rvZSbrYets7i2sStcsvVG0Jfb0EL5ghlf+ihkDP5iAtL Yc7YGXqvXP6rmG0JB7Euzc2mqzuAqmEAbhfjR9kI/Vo//OuNEeYTp1ya40hPfz7PCsIm w5vA== MIME-Version: 1.0 X-Received: by 10.224.166.6 with SMTP id k6mr31790021qay.39.1373543746612; Thu, 11 Jul 2013 04:55:46 -0700 (PDT) Sender: rmh.aybabtu@gmail.com Received: by 10.49.26.193 with HTTP; Thu, 11 Jul 2013 04:55:46 -0700 (PDT) Date: Thu, 11 Jul 2013 13:55:46 +0200 X-Google-Sender-Auth: mmUzd2NJHL1ud_0q5FD1oHDGU-4 Message-ID: Subject: libdwarf get_*_desc functions From: Robert Millan To: freebsd-arch@freebsd.org, jb@freebsd.org Content-Type: text/plain; charset=UTF-8 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, 11 Jul 2013 11:55:47 -0000 Hi, Regarding these four libdwarf.so symbols: 00000000000048c0 T get_attr_desc 0000000000004ae0 T get_form_desc 0000000000004770 T get_sht_desc 0000000000004bb0 T get_tag_desc I've observed that: - They don't follow the usual libdwarf naming convention (dwarf_*). and - They aren't used anywhere else in world. This makes me suspect their purpose is only for internal use within libdwarf. Is it intentional that they're public symbols? -- Robert Millan From owner-freebsd-arch@FreeBSD.ORG Fri Jul 12 20:48: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 0E5F240D for ; Fri, 12 Jul 2013 20:48:07 +0000 (UTC) (envelope-from lidl@pix.net) Received: from hydra.pix.net (hydra.pix.net [IPv6:2001:470:e254::3c]) by mx1.freebsd.org (Postfix) with ESMTP id DDAB91E13 for ; Fri, 12 Jul 2013 20:48:06 +0000 (UTC) Received: from torb.pix.net (torb.pix.net [IPv6:2001:470:e254:10:12dd:b1ff:febf:eca9]) (authenticated bits=0) by hydra.pix.net (8.14.5/8.14.5) with ESMTP id r6CKm5w4061878 for ; Fri, 12 Jul 2013 16:48:05 -0400 (EDT) (envelope-from lidl@pix.net) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97.8 at mail.pix.net Message-ID: <51E06B85.10109@pix.net> Date: Fri, 12 Jul 2013 16:48:05 -0400 From: Kurt Lidl User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: freebsd-arch@freebsd.org Subject: Re: Adding a MACHINE_ARCH note References: In-Reply-To: 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, 12 Jul 2013 20:48:07 -0000 > On Jul 10, 2013, at 03:08, Peter Wemm wrote: >> On Tue, Jul 9, 2013 at 5:56 PM, Adrian Chadd wrote: >>> ... boy I'd like to see this particular x86 hiccup fixed before this >>> stuff is mainstream. >> >> I'm not entirely sure how much support there is behind "x32". I don't >> know if its much more than an academic curiosity or if there's real >> demand for it. > > It seems to be driven by Intel and Google. The idea is that for some > applications (or maybe even most :), an ILP32 model will perform better. I believe that Google's NaCl (native client) plugins for Chrome all use the "x32" ABI. The NaCl stuff uses this, along with a "safe" code generation path to implement part of the sandboxing for Chrome plugins. Ultimately, to have a fully functioning Chrome (with plugins) on amd64 hosts, we'll want to support "x32". -Kurt From owner-freebsd-arch@FreeBSD.ORG Fri Jul 12 22:25: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 CBC023FD; Fri, 12 Jul 2013 22:25:22 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) by mx1.freebsd.org (Postfix) with ESMTP id A8A0712A3; Fri, 12 Jul 2013 22:25:22 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 0637BB987; Fri, 12 Jul 2013 18:25:22 -0400 (EDT) From: John Baldwin To: freebsd-arch@freebsd.org Subject: Re: Extending MADV_PROTECT Date: Fri, 12 Jul 2013 17:48:57 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <201305071433.27993.jhb@freebsd.org> <20130522084145.GJ3047@kib.kiev.ua> <201306281446.01797.jhb@freebsd.org> In-Reply-To: <201306281446.01797.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201307121748.57778.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 12 Jul 2013 18:25:22 -0400 (EDT) Cc: Konstantin Belousov , arch@freebsd.org, "Robert N. M. Watson" , Jilles Tjoelker 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, 12 Jul 2013 22:25:22 -0000 On Friday, June 28, 2013 2:46:01 pm John Baldwin wrote: > Ok, there isn't really a clear consensus here, but I need a system call to let > me toggle this flag on existing processes. > > One reason I don't like the procctl() approach is I am uneasy about forcing > a certain behavior for how commands treat pgid (first-fail vs best-effort). > I guess it can always change in the future so that isn't completely unsolvable. > > I guess I am fine just making it use hardcoded sizes instead of full-blown > ioctl encoding. Ok, I have updated patches for this for HEAD. I have not yet implemented the inheritance bits because I'm loathe to add the first bit to a p_flag2. :-P However, if that's the best course of action I suppose we can do that. The kernel patch is at www.freebsd.org/~jhb/patches/procctl.patch The patch for the protect binary is at www.freebsd.org/~jhb/patches/protect.patch -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Fri Jul 12 23:02:05 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 C503F320 for ; Fri, 12 Jul 2013 23:02:05 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) by mx1.freebsd.org (Postfix) with ESMTP id 61B8915DB for ; Fri, 12 Jul 2013 23:02:05 +0000 (UTC) Received: by mail-we0-f171.google.com with SMTP id m46so8520049wev.16 for ; Fri, 12 Jul 2013 16:02:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=6NMyVMeMIUYfPVr5Z51/jstEhRBPXCTX+iDmJtMY3wQ=; b=0Gb7rxj01YlsAcICeYnwAZ/dFD2xBY6YXVBntkJ8Dj63LlLT6g9YYwBW8vwfHEaD9e kp3c1288KTwYGSN4Lz/Z9wURjcazpuK/yGMomOBDZLCH840kIMXy6H29dzt/QP/SOi/P +ViWLJt/tZDCLPK8BoqJvWP8nVMeepNKsPaU2qHw3DCazIhS78k8mf7XKnv8RfE791I4 gEbLTdzN2hEYMnzwd7DK93aNMvz9/nJhJPn2SRl2gNxAefp6iZNUchKVjbK6kw282Vx+ gwtEtVppWJrXyCSmYADGL+TDIxyDwzrUoANtNSNhziKqykg6Ur63d8QS+KLdwJfTzWbj 2tMg== MIME-Version: 1.0 X-Received: by 10.194.240.201 with SMTP id wc9mr25513406wjc.1.1373670124307; Fri, 12 Jul 2013 16:02:04 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.94.132 with HTTP; Fri, 12 Jul 2013 16:02:04 -0700 (PDT) In-Reply-To: <51E06B85.10109@pix.net> References: <51E06B85.10109@pix.net> Date: Fri, 12 Jul 2013 16:02:04 -0700 X-Google-Sender-Auth: 7OyqyjQf4BhRpoL1n0Jlx4XAc2A Message-ID: Subject: Re: Adding a MACHINE_ARCH note From: Adrian Chadd To: Kurt Lidl Content-Type: text/plain; charset=ISO-8859-1 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, 12 Jul 2013 23:02:05 -0000 On 12 July 2013 13:48, Kurt Lidl wrote: >> It seems to be driven by Intel and Google. The idea is that for some >> applications (or maybe even most :), an ILP32 model will perform better. > > > I believe that Google's NaCl (native client) plugins for Chrome all use > the "x32" ABI. The NaCl stuff uses this, along with a "safe" code > generation path to implement part of the sandboxing for Chrome plugins. > > Ultimately, to have a fully functioning Chrome (with plugins) on amd64 > hosts, we'll want to support "x32". Does this mean that netbooks with only 32 bit CPUs in them won't support NaCl? (Ie, they're only ever going to generate x32 code, and even 32 bit machines will still run 64 bit assembly..) -adrian From owner-freebsd-arch@FreeBSD.ORG Sat Jul 13 03:05:12 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 4A3E7CC8; Sat, 13 Jul 2013 03:05:12 +0000 (UTC) (envelope-from lidl@pix.net) Received: from hydra.pix.net (hydra.pix.net [IPv6:2001:470:e254::3c]) by mx1.freebsd.org (Postfix) with ESMTP id 255DA1DD6; Sat, 13 Jul 2013 03:05:12 +0000 (UTC) Received: from torb.pix.net (torb.pix.net [IPv6:2001:470:e254:10:12dd:b1ff:febf:eca9]) (authenticated bits=0) by hydra.pix.net (8.14.5/8.14.5) with ESMTP id r6D35BdB083045; Fri, 12 Jul 2013 23:05:11 -0400 (EDT) (envelope-from lidl@pix.net) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97.8 at mail.pix.net Message-ID: <51E0C3E7.7000503@pix.net> Date: Fri, 12 Jul 2013 23:05:11 -0400 From: Kurt Lidl User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: Adding a MACHINE_ARCH note References: <51E06B85.10109@pix.net> In-Reply-To: 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, 13 Jul 2013 03:05:12 -0000 On 7/12/13 7:02 PM, Adrian Chadd wrote: > On 12 July 2013 13:48, Kurt Lidl wrote: >>> It seems to be driven by Intel and Google. The idea is that for some >>> applications (or maybe even most :), an ILP32 model will perform better. >> >> >> I believe that Google's NaCl (native client) plugins for Chrome all use >> the "x32" ABI. The NaCl stuff uses this, along with a "safe" code >> generation path to implement part of the sandboxing for Chrome plugins. >> >> Ultimately, to have a fully functioning Chrome (with plugins) on amd64 >> hosts, we'll want to support "x32". > > Does this mean that netbooks with only 32 bit CPUs in them won't support NaCl? > (Ie, they're only ever going to generate x32 code, and even 32 bit > machines will still run 64 bit assembly..) I don't think so. If you grovel through the NaCl stuff, you have to gen bit 32-bit x86, as well as x32 mad64 stuff, and they encourage ARM too. It's a shifting landscape, and they are now working on some intermediate PNaCl (portable), which smells like LLVM's IR code that they can convert to your native ISA at runtime. -Kurt From owner-freebsd-arch@FreeBSD.ORG Sat Jul 13 13:26:58 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E67D66FC for ; Sat, 13 Jul 2013 13:26:58 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from smtpauth4.wiscmail.wisc.edu (wmauth4.doit.wisc.edu [144.92.197.145]) by mx1.freebsd.org (Postfix) with ESMTP id C3179106F for ; Sat, 13 Jul 2013 13:26:58 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from avs-daemon.smtpauth4.wiscmail.wisc.edu by smtpauth4.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) id <0MPV00I00L5T3I00@smtpauth4.wiscmail.wisc.edu> for freebsd-arch@freebsd.org; Sat, 13 Jul 2013 08:26:57 -0500 (CDT) X-Spam-PmxInfo: Server=avs-4, Version=6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.7.13.131821, SenderIP=0.0.0.0 X-Spam-Report: AuthenticatedSender=yes, SenderIP=0.0.0.0 Received: from comporellon.tachypleus.net (unknown [76.210.63.131]) by smtpauth4.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) with ESMTPSA id <0MPV00A67MOWPG10@smtpauth4.wiscmail.wisc.edu> for freebsd-arch@freebsd.org; Sat, 13 Jul 2013 08:26:57 -0500 (CDT) Message-id: <51E155A0.6030409@freebsd.org> Date: Sat, 13 Jul 2013 08:26:56 -0500 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130711 Thunderbird/17.0.7 To: freebsd-arch@freebsd.org Subject: Re: Adding a MACHINE_ARCH note References: <51E06B85.10109@pix.net> In-reply-to: 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, 13 Jul 2013 13:26:59 -0000 On 07/12/13 18:02, Adrian Chadd wrote: > On 12 July 2013 13:48, Kurt Lidl wrote: >>> It seems to be driven by Intel and Google. The idea is that for some >>> applications (or maybe even most :), an ILP32 model will perform better. >> >> I believe that Google's NaCl (native client) plugins for Chrome all use >> the "x32" ABI. The NaCl stuff uses this, along with a "safe" code >> generation path to implement part of the sandboxing for Chrome plugins. >> >> Ultimately, to have a fully functioning Chrome (with plugins) on amd64 >> hosts, we'll want to support "x32". > Does this mean that netbooks with only 32 bit CPUs in them won't support NaCl? > (Ie, they're only ever going to generate x32 code, and even 32 bit > machines will still run 64 bit assembly..) > As I remember, they are trying to have a constant ABI (32-bit pointers, little endian) irrespective of the actual architecture to make things really just a recompile. Basically, it's meant to be something where sizeof(everything) is the same both on x86 and little-endian ARM. So this means there is 32-bit x86 and x32, but not amd64. -Nathan From owner-freebsd-arch@FreeBSD.ORG Sat Jul 13 17:58:40 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 8199CF6D; Sat, 13 Jul 2013 17:58:40 +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 23EE71AF9; Sat, 13 Jul 2013 17:58:39 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r6DHwZOS024608; Sat, 13 Jul 2013 20:58:35 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r6DHwZOS024608 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r6DHwZJA024606; Sat, 13 Jul 2013 20:58:35 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 13 Jul 2013 20:58:35 +0300 From: Konstantin Belousov To: John Baldwin Subject: Re: Extending MADV_PROTECT Message-ID: <20130713175835.GN91021@kib.kiev.ua> References: <201305071433.27993.jhb@freebsd.org> <20130522084145.GJ3047@kib.kiev.ua> <201306281446.01797.jhb@freebsd.org> <201307121748.57778.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="JTLHU1qSfROtVZpA" Content-Disposition: inline In-Reply-To: <201307121748.57778.jhb@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: arch@freebsd.org, "Robert N. M. Watson" , Jilles Tjoelker , 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, 13 Jul 2013 17:58:40 -0000 --JTLHU1qSfROtVZpA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 12, 2013 at 05:48:57PM -0400, John Baldwin wrote: > On Friday, June 28, 2013 2:46:01 pm John Baldwin wrote: > > Ok, there isn't really a clear consensus here, but I need a system call= to let > > me toggle this flag on existing processes. > >=20 > > One reason I don't like the procctl() approach is I am uneasy about for= cing > > a certain behavior for how commands treat pgid (first-fail vs best-effo= rt). > > I guess it can always change in the future so that isn't completely uns= olvable. > >=20 > > I guess I am fine just making it use hardcoded sizes instead of full-bl= own > > ioctl encoding. >=20 > Ok, I have updated patches for this for HEAD. I have not yet implemented= the > inheritance bits because I'm loathe to add the first bit to a p_flag2. :-P > However, if that's the best course of action I suppose we can do that. >=20 > The kernel patch is at www.freebsd.org/~jhb/patches/procctl.patch >=20 > The patch for the protect binary is at www.freebsd.org/~jhb/patches/prote= ct.patch >=20 It seems that p_cansee() is called twice, once in kern_procctl(), and then in protect_setchild(). Is AUE_WAIT6 the correct audit event id for procctl ? I thought proposing to use pget() for P_PID case in kern_procctl(), but indeed open coding of the process lookup is easier, since otherwise you would need to move proctree_lock acquisition to P_PGID. Why do you need PPROT_CLEAR ? If you do need the flag, would it be better to assign a non-zero value to it ? --JTLHU1qSfROtVZpA Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJR4ZVKAAoJEJDCuSvBvK1B4y0QAJAbUl/UV7iJUjU7tAjWc3Cv WZDN0273hxxMmTay18YyDDAVSTN9LJUm4lzh6MCYrrtjgb7gO8/kFmZ6f2VBc8i8 oXHcQRxBd7s+foXjCj8Jzf04yU9VY79+fhb3qC9Zku4yfRQkcrhTvZorqJrrd89j It+WMQpibhZQD5MP0GRc+YmARNb2MUXcZemO9axT4QV2xv1l3C+Zq98fU+mWIG4q 4pTmi+3J4hCjT+oVzS+dczixeTk/3zQeYoaaz2PeOBRaXAlXAX6yet3N+qbVlASz zL2lgDFRiTZqMnHaej4Scv5ncPnugVRS6i//hVtgdNoQX9U5EslEp9aZQtR3bVpr ntjTjLB7Rz/1aU2LqJqtw7arBFtHAEsxvnzp+r7jMGsaVJHjY/grBqOX3nC+OtWg dEcGMnhM7+nMJY9VDolq48S5bdPzo/DsF5RBWG7p8+wMJd20eVTDm3zsS1n+FhBP pCfNOqlDfBOotq2JOK3q4eg9RIoHUF9N7FmBtzWxz/aJLKcCRHbW7iTU710A3rup YVDNFDFY85yKt5mt5ES/gMdLFMDxZlW502wNz8zzvSkZ4Iz0rdni6W2rUBShRco+ kLBEtzbkE4V3Y7+Pb07NjFR3MuE5DpVw1NdUOaLnZi2fd7s/uej4i8/AY1J/dV12 YVfCqPWItmJgWL3l8WNQ =sLAy -----END PGP SIGNATURE----- --JTLHU1qSfROtVZpA-- From owner-freebsd-arch@FreeBSD.ORG Sat Jul 13 21:40:42 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 84988680; Sat, 13 Jul 2013 21:40:42 +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 46EFD10DD; Sat, 13 Jul 2013 21:40:42 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 5B2E43592E7; Sat, 13 Jul 2013 23:40:39 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 1677) id 425E528494; Sat, 13 Jul 2013 23:40:39 +0200 (CEST) Date: Sat, 13 Jul 2013 23:40:39 +0200 From: Jilles Tjoelker To: Robert Millan Subject: Re: libutil in Debian Message-ID: <20130713214039.GA36164@stack.nl> References: <6E057FD0-9054-44CD-A806-3AFD8A7196CC@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Konstantin Belousov , Justin Hibbits , Tijl Coosemans , Gleb Smirnoff , 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, 13 Jul 2013 21:40:42 -0000 On Thu, Jul 11, 2013 at 10:42:18AM +0200, Robert Millan wrote: > 2013/7/9 Justin Hibbits : > > I was thinking more in terms of adding the functions to the debian local > > patch set. I don't know how intrusive it would be, but it may be worth > > looking into. > You may not believe this, but it is even worse. Can you believe they > even refused to add trivial syscall stubs, such as nlm_syscall()? They > say this "belongs elsewhere" even though it's -lc in FreeBSD like most > (all?) syscall stubs. > Look at the kind of workarounds we have to endure: > http://anonscm.debian.org/viewvc/glibc-bsd/trunk/freebsd-utils/debian/patches/036_nfs_glibc.diff?revision=4047&view=markup glibc upstream appears indecisive about whether to add stubs for special-use syscalls. There are more packages with their own stubs. Note that FreeBSD libc has nlm_syscall() under the FBSDprivate_1.0 symbol version, reflecting the lower level of guarantees about its ABI because it is only supposed to be used by rpc.lockd. > Heck, even the trivial update to , which was *already* of > BSD origin since ancient times, was restricted to only apply on our > port, so that the new macros (e.g. LIST_FOREACH_SAFE) were not > available on Debian GNU/Linux. I would say that a Debian patch is indeed not the first thing to try for a update, since it makes things incompatible between Linux distributions. Rather, that should be done in glibc upstream. About copyright assignment, note that the original file is already not copyright FSF and was added to glibc anyway. -- Jilles Tjoelker From owner-freebsd-arch@FreeBSD.ORG Sat Jul 13 21:52:42 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 914048C9; Sat, 13 Jul 2013 21:52:42 +0000 (UTC) (envelope-from rmh.aybabtu@gmail.com) Received: from mail-qa0-x22f.google.com (mail-qa0-x22f.google.com [IPv6:2607:f8b0:400d:c00::22f]) by mx1.freebsd.org (Postfix) with ESMTP id 2F8441137; Sat, 13 Jul 2013 21:52:42 +0000 (UTC) Received: by mail-qa0-f47.google.com with SMTP id i13so958851qae.20 for ; Sat, 13 Jul 2013 14:52:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=v0uqVWMwKJOVjw7YNULGmm51RxmtpE1ZM310+Y+8h6c=; b=K/7ZFvr76hXDu4SPolckqIpOMquip8QEzIlPtkFjkygrqJtpguvcFBRsoSOWpgg4w7 eIi7XIRK+sz9Q5NGEXA3l+I2tKUcFGvFdehw4LhEfGlc/kVOi2HLQk9BSsnas5AP5X56 6AuPOC60lxVIorvziUpgA2fIKcWhgQokPJPTd0KgEBHHkpL9qojhFwAf5IIML4XOekVj BD2pWloGI6Ql5L3znVLOMp+LFhzOESDT/+0po/mPAWRxaflHUTpQVIMjlEjxOzFB2ahN VviDQ+glrXcY2xFlCstbxEB8TNh1UVp+oatEvTawysUxMzrtb31Bz+ZUr9wo4G99XO1u iUEQ== MIME-Version: 1.0 X-Received: by 10.224.63.7 with SMTP id z7mr45225799qah.51.1373752361712; Sat, 13 Jul 2013 14:52:41 -0700 (PDT) Sender: rmh.aybabtu@gmail.com Received: by 10.49.26.193 with HTTP; Sat, 13 Jul 2013 14:52:41 -0700 (PDT) In-Reply-To: <20130713214039.GA36164@stack.nl> References: <6E057FD0-9054-44CD-A806-3AFD8A7196CC@bsdimp.com> <20130713214039.GA36164@stack.nl> Date: Sat, 13 Jul 2013 23:52:41 +0200 X-Google-Sender-Auth: iqaL0b8Xd_BHnmfzLapitxw1r94 Message-ID: Subject: Re: libutil in Debian From: Robert Millan To: Jilles Tjoelker Content-Type: text/plain; charset=UTF-8 Cc: Konstantin Belousov , Justin Hibbits , Tijl Coosemans , Gleb Smirnoff , 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, 13 Jul 2013 21:52:42 -0000 2013/7/13 Jilles Tjoelker : > I would say that a Debian patch is indeed not the first thing to try for > a update, since it makes things incompatible between Linux > distributions. Rather, that should be done in glibc upstream. About > copyright assignment, note that the original file is already not > copyright FSF and was added to glibc anyway. What you say makes sense but in practice doesn't really work. If you don't believe me, just try. I'll be happy to be proven wrong :-) But please bear with me if I don't want to spend my own time in it. We're still waiting [1] for them to stop colliding with "__unused" in their own headers (fortunately, it just requires an excruciatingly complicated kludge [2] to get around this one). [1] http://sourceware.org/ml/libc-ports/2012-01/msg00000.html [2] http://anonscm.debian.org/viewvc/glibc-bsd/trunk/freebsd-glue/include/netdb.h?revision=4718&view=co -- Robert Millan From owner-freebsd-arch@FreeBSD.ORG Sat Jul 13 22:33: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 17D82EBB; Sat, 13 Jul 2013 22:33:23 +0000 (UTC) (envelope-from crodr001@gmail.com) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) by mx1.freebsd.org (Postfix) with ESMTP id 665FA122E; Sat, 13 Jul 2013 22:33:22 +0000 (UTC) Received: by mail-lb0-f175.google.com with SMTP id r10so8345219lbi.6 for ; Sat, 13 Jul 2013 15:33:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=aNfBWinDJxcoQeqOlf69jfScnlp172BfMBZWmCH/69g=; b=XmLNyQNGJNP7nO5Dda20OGTXVuY9421Vtj+9/e1SX2pCp4e3NtrH/0xdRoGln0aTUG /wsyYk4d7O+cUnVqKNP8ee9n78VabyVWKoN3jtWUJZjBrVAaCmgodHoPxmWipvtICcX4 YPi/69KLtGVjLOlCwhm87C1rXB9Fsu62+em95KN6eaARHec6Rvw9ysG3L6BzgIZjiJW0 51fCsPwf/VLFObKAKDwrmSuMry3TizmfH+nibUM0lJpZtiRqERLngmjfIsDEE3c+I2tz /G8B94LRLWQEf6gzpzhF2HgHI8+rnWgUrIOiA1/CZENr0/fPmmpctBBzsTeuSQcRbCIm QVRA== MIME-Version: 1.0 X-Received: by 10.152.4.65 with SMTP id i1mr22012115lai.21.1373754801358; Sat, 13 Jul 2013 15:33:21 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.149.38 with HTTP; Sat, 13 Jul 2013 15:33:21 -0700 (PDT) In-Reply-To: References: Date: Sat, 13 Jul 2013 15:33:21 -0700 X-Google-Sender-Auth: hgbRuvHZ6_dKYvZF-wyB1ETgXaI Message-ID: Subject: Re: [RFC] Review of mount.conf man page From: Craig Rodrigues To: Benjamin Kaduk Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Marcel Moolenaar , 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, 13 Jul 2013 22:33:23 -0000 On Mon, Jul 8, 2013 at 2:55 PM, Benjamin Kaduk wrote: > > > A few notes: our style for man pages (mdoc) is to start a new line for new sentences. I am not sure that the .Cm macro is appropriate to describe .onfail and friends; I guess that devd.conf.5 is using .Ic which might be better. The default font for .Em is supposedly italic, so it may not be best for the mountroot prompt, either. I'm not sure why there are square brackets around the 'N' argument to .timeout; does the default behavior of 3 seconds apply to a .timeout without 'N', or the absence of a .timeout? Can you double-check whether .Pp is needed after .Ed? I have incorporated your review comments: (1) replaced .Cm with .Ic (2) replaced .Em with .Li (3) remove square brackets around 'N' argument to timeout and 'file' argument to .md (4) Started new sentences on new lines I regenerated my diff and patch: http://people.freebsd.org/~rodrigc/mount-conf/mount.conf.diff.txt http://people.freebsd.org/~rodrigc/mount-conf/mount.conf.8.txt Some comments: (1) Refer to src/sys/kern/vfs_mountroot.c, in the parse_dir_timeout() function for the logic of how .timeout is parsed. If no .timeout directive is specified in .mount.conf, then the default timeout value will be used (3 seconds). If .timeout has a numerical argument, then that will set the value of .timeout. If .timeout has no argument, or an argument that strtol() fails on, then the timeout value will not be reset. In that case, the timeout value will either be the default 3 seconds, or if ".timeout N" was correctly specified previous to this line, then N will be used as the timeout. (2) .Pp is not needed *before* .Bd, because .Bd adds vertical space. However .Pp *is* needed after .Ed which does not add vertical space afterwards. ports.7 is one example man page which has examples of this. -- Craig