From owner-freebsd-arch@FreeBSD.ORG Sun Mar 4 12:33:41 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3A7F9106566C for ; Sun, 4 Mar 2012 12:33:41 +0000 (UTC) (envelope-from johnandsara2@cox.net) Received: from eastrmfepo102.cox.net (eastrmfepo102.cox.net [68.230.241.214]) by mx1.freebsd.org (Postfix) with ESMTP id C72878FC14 for ; Sun, 4 Mar 2012 12:33:40 +0000 (UTC) Received: from eastrmimpo210.cox.net ([68.230.241.225]) by eastrmfepo102.cox.net (InterMail vM.8.01.04.00 201-2260-137-20101110) with ESMTP id <20120304123335.XFXD26743.eastrmfepo102.cox.net@eastrmimpo210.cox.net>; Sun, 4 Mar 2012 07:33:35 -0500 Received: from [192.168.3.22] ([70.177.172.35]) by eastrmimpo210.cox.net with bizsmtp id hQZa1i0070mAvba02QZaqz; Sun, 04 Mar 2012 07:33:34 -0500 X-CT-Class: Clean X-CT-Score: 0.00 X-CT-RefID: str=0001.0A02020A.4F53611E.00D2,ss=1,re=0.000,fgs=0 X-CT-Spam: 0 X-Authority-Analysis: v=1.1 cv=UX0yTbQhWqpAAGgYJGbRwl7xWumxupoqUww6HaD4jqE= c=1 sm=1 a=f5xKl4ys9bwA:10 a=AeehsHawFTcA:10 a=G8Uczd0VNMoA:10 a=Wajolswj7cQA:10 a=8nJEP1OIZ-IA:10 a=alU6Bxxa4qBWIf+k8j/ISQ==:17 a=kviXuzpPAAAA:8 a=vU8MbuIS78hpw1yIOJwA:9 a=wPNLvfGTeEIA:10 a=4vB-4DCPJfMA:10 a=alU6Bxxa4qBWIf+k8j/ISQ==:117 X-CM-Score: 0.00 Authentication-Results: cox.net; none Message-ID: <4F53611C.8000905@cox.net> Date: Sun, 04 Mar 2012 07:33:32 -0500 From: "John D. Hendrickson and Sara Darnell" User-Agent: Thunderbird 2.0.0.24 (X11/20100228) MIME-Version: 1.0 To: Ed Schouten References: <4E18ABB1.4010304@cox.net> <20110709194639.GA4914@elie> <4E18EE60.7010402@cox.net> <20110710151354.GA25475@r500-debian> <4F50FD4D.9000106@cox.net> <20120302183138.GC32748@hoeg.nl> <4F5227FE.3080708@cox.net> <20120303151239.GF32748@hoeg.nl> In-Reply-To: <20120303151239.GF32748@hoeg.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arch@freebsd.org Subject: Re: dep-trace v. tsort (mac ports depends support) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: johnandsara2@cox.net List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2012 12:33:41 -0000 No and no again. BSD already uses tsort(1) during portage which is NOT OPTIONAL. It is not for you to like or dislike. You've missed the point of "depends" altogether. You don't have high level software capability until after it is installed or ported : both need or require order. Thank you -- John Ed Schouten wrote: > Hi John, > > * John D. Hendrickson and Sara Darnell , 20120303 15:17: >> Who knows to order depends so tsort can order them in non-topological >> order as output? Who has time to SVG plot program compile order (or >> pkg) depends like airports and airplanes and draw arrows between >> them? >> >> Another issue of pre-positioning each sublists in port files : you >> are SOL if there is any loss of order before tsort gets them. >> >> Another issue (one port not knowing the full sublist of the other) >> (there are probably more I'll stop there). > But the point is that if applications are looking for such things, they > are typically implemented in a higher-level programming language that > allows them to implement such features themselves, instead of relying on > a 1980s command line tool. From owner-freebsd-arch@FreeBSD.ORG Sun Mar 4 12:44:02 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8572A1065672; Sun, 4 Mar 2012 12:44:02 +0000 (UTC) (envelope-from rmh.aybabtu@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 267F88FC13; Sun, 4 Mar 2012 12:44:01 +0000 (UTC) Received: by iahk25 with SMTP id k25so5853988iah.13 for ; Sun, 04 Mar 2012 04:44:01 -0800 (PST) Received-SPF: pass (google.com: domain of rmh.aybabtu@gmail.com designates 10.50.87.225 as permitted sender) client-ip=10.50.87.225; Authentication-Results: mr.google.com; spf=pass (google.com: domain of rmh.aybabtu@gmail.com designates 10.50.87.225 as permitted sender) smtp.mail=rmh.aybabtu@gmail.com; dkim=pass header.i=rmh.aybabtu@gmail.com Received: from mr.google.com ([10.50.87.225]) by 10.50.87.225 with SMTP id bb1mr1604762igb.13.1330865041639 (num_hops = 1); Sun, 04 Mar 2012 04:44:01 -0800 (PST) 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=uALwYaIlqRwImTVw4jdTiFSz+Ky4q0+J4GOtT1SLX80=; b=HsZaFpf86Yl7ynK4UWqEl1zy+JcLzriz2t08EaiGBECavQYTsXgSnElCXXViiNe0S2 sHF/cyZH8h19XmmKFEq3Oz8wsUJP4xkrUaWFzrHwecJw+7LvzZBr2/J+bzAqtvwVuxKf oTkg3DnDpEO4UVzsprXuQ6HygOLliOwXKj9w0ILbK02/J8DgZEBrXaBCuxIccJ+gohSA aKjRFSorOgvR17lRg6/Gt6ks9mye+hjj09t6agYFzdWBg4BoRWHU4XgRtviFwvI4Zuj4 9etS3hMxICseNKgQZHIeW1ShuuoFHnyE7RyejUyj+8ymst4XrLmN2efQqHZhlOKk4wCo 3reA== MIME-Version: 1.0 Received: by 10.50.87.225 with SMTP id bb1mr1346620igb.13.1330865041584; Sun, 04 Mar 2012 04:44:01 -0800 (PST) Sender: rmh.aybabtu@gmail.com Received: by 10.43.130.201 with HTTP; Sun, 4 Mar 2012 04:44:01 -0800 (PST) In-Reply-To: References: <201202181720.27135.hselasky@c2i.net> <20120303124805.GA4725@thorin> <201203031902.11035.hselasky@c2i.net> Date: Sun, 4 Mar 2012 13:44:01 +0100 X-Google-Sender-Auth: ezhKgjgXijjDbmluZ460OVKAUmc Message-ID: From: Robert Millan To: Warner Losh Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Kostik Belousov , Adrian Chadd , freebsd-arch@freebsd.org, freebsd-usb@freebsd.org, Hans Petter Selasky Subject: Re: Exclude USB drivers from main kernel image? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2012 12:44:02 -0000 El 3 de mar=C3=A7 de 2012 19:37, Warner Losh ha escrit: >> Hi, >> >> Your patch looks good. >> >> Are there any objections committing the patch attached to the previous e= -mail? > > Do all the platforms that had the devices removed work? =C2=A0Have they a= ll been tested? I've tested the i386 flavour on a FreeBSD VM. It boots and successfully loads ums.ko. Aside from that, a very similar setup has been tested for i386 and amd64 on Debian GNU/kFreeBSD, for several months. I'm unable to test the other architectures. But if you're more comfortable that way, I have no problem with excluding them from my patch. --=20 Robert Millan From owner-freebsd-arch@FreeBSD.ORG Sun Mar 4 20:05:47 2012 Return-Path: Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5D80D1065677; Sun, 4 Mar 2012 20:05:47 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 102428FC29; Sun, 4 Mar 2012 20:05:46 +0000 (UTC) Received: from 63.imp.bsdimp.com (63.imp.bsdimp.com [10.0.0.63]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id q24K0hmW010484 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Sun, 4 Mar 2012 13:00:43 -0700 (MST) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Warner Losh In-Reply-To: Date: Sun, 4 Mar 2012 13:00:43 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201202181720.27135.hselasky@c2i.net> <20120303124805.GA4725@thorin> <201203031902.11035.hselasky@c2i.net> To: Robert Millan X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Sun, 04 Mar 2012 13:00:44 -0700 (MST) Cc: Kostik Belousov , Adrian Chadd , freebsd-arch@FreeBSD.ORG, freebsd-usb@FreeBSD.ORG, Hans Petter Selasky Subject: Re: Exclude USB drivers from main kernel image? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2012 20:05:47 -0000 On Mar 4, 2012, at 5:44 AM, Robert Millan wrote: > El 3 de mar=E7 de 2012 19:37, Warner Losh ha escrit: >>> Hi, >>>=20 >>> Your patch looks good. >>>=20 >>> Are there any objections committing the patch attached to the = previous e-mail? >>=20 >> Do all the platforms that had the devices removed work? Have they = all been tested? >=20 > I've tested the i386 flavour on a FreeBSD VM. It boots and > successfully loads ums.ko. >=20 > Aside from that, a very similar setup has been tested for i386 and > amd64 on Debian GNU/kFreeBSD, for several months. >=20 > I'm unable to test the other architectures. But if you're more > comfortable that way, I have no problem with excluding them from my > patch. It is the other architectures that I'm specifically worried about. I = know that x86 flavors will work even without testing them specifically = since I've been doing something akin to this for years. I've not had = good luck always with arm and mips platforms and USB, so I'd feel better = if we could get some testing done there. I'll see what I can dig up = from my board pile to test, but my coverage will be limited. Read this as a "go ahead with x86, please wait on the others for more = data" from me. Warner From owner-freebsd-arch@FreeBSD.ORG Sun Mar 4 21:32:20 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9358010656EF; Sun, 4 Mar 2012 21:32:20 +0000 (UTC) (envelope-from rmh.aybabtu@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 302E88FC21; Sun, 4 Mar 2012 21:32:19 +0000 (UTC) Received: by iahk25 with SMTP id k25so6403509iah.13 for ; Sun, 04 Mar 2012 13:32:19 -0800 (PST) Received-SPF: pass (google.com: domain of rmh.aybabtu@gmail.com designates 10.42.18.195 as permitted sender) client-ip=10.42.18.195; Authentication-Results: mr.google.com; spf=pass (google.com: domain of rmh.aybabtu@gmail.com designates 10.42.18.195 as permitted sender) smtp.mail=rmh.aybabtu@gmail.com; dkim=pass header.i=rmh.aybabtu@gmail.com Received: from mr.google.com ([10.42.18.195]) by 10.42.18.195 with SMTP id y3mr11892388ica.13.1330896739585 (num_hops = 1); Sun, 04 Mar 2012 13:32:19 -0800 (PST) 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=Jm02xD7baIZPnLguE5ldxrbdXJiD1NUKaLGtXtARfbE=; b=IA/cxv8iiTLvfvOkHFVY2SLJ8g7QRIuQPuv69RFY4Nj6x1SkgE78hV85dC4BPkJijd kFC5HmgE0/ay45CdwWxrovrSeR8MwT+/ZQkLtYupMWJOOwyDRkF+XgXO0ATJnSosDcOo WmEf96/64HlDwzcA0S/48CcpfvkF6vuxdlgIk8Iu/9ZdVVNto11x5dWqgSd+YbT3nGnT 1cJyzpvAq6Nzvqb2Mykh2aAqZ4VremdRv/iWAdZCpwcRMb5CXXiDPtVbMwTX3qyEIL+J Ry2bNKwpsgaesAPIWuFqRvpuyp7IMtgB1DJCRTUuN5/Krt8lSKItANiYgkSYaNFJ1z1R XHDg== MIME-Version: 1.0 Received: by 10.42.18.195 with SMTP id y3mr9823051ica.13.1330896739516; Sun, 04 Mar 2012 13:32:19 -0800 (PST) Sender: rmh.aybabtu@gmail.com Received: by 10.43.130.201 with HTTP; Sun, 4 Mar 2012 13:32:19 -0800 (PST) In-Reply-To: References: <201202181720.27135.hselasky@c2i.net> <20120303124805.GA4725@thorin> <201203031902.11035.hselasky@c2i.net> Date: Sun, 4 Mar 2012 22:32:19 +0100 X-Google-Sender-Auth: Mifdsx4K7YB5UEjKt6Os95CpJww Message-ID: From: Robert Millan To: Warner Losh Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Kostik Belousov , Adrian Chadd , freebsd-arch@freebsd.org, freebsd-usb@freebsd.org, Hans Petter Selasky Subject: Re: Exclude USB drivers from main kernel image? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2012 21:32:20 -0000 El 4 de mar=C3=A7 de 2012 21:00, Warner Losh ha escrit: > It is the other architectures that I'm specifically worried about. =C2=A0= I know that x86 flavors will work even without testing them specifically si= nce I've been doing something akin to this for years. =C2=A0I've not had go= od luck always with arm and mips platforms and USB, so I'd feel better if w= e could get some testing done there. =C2=A0I'll see what I can dig up from = my board pile to test, but my coverage will be limited. > > Read this as a "go ahead with x86, please wait on the others for more dat= a" from me. Okay, I just committed x86 bits (after mentor approval). --=20 Robert Millan From owner-freebsd-arch@FreeBSD.ORG Mon Mar 5 19:31:34 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 94A0B106564A for ; Mon, 5 Mar 2012 19:31:34 +0000 (UTC) (envelope-from ray@ddteam.net) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by mx1.freebsd.org (Postfix) with ESMTP id 24E918FC14 for ; Mon, 5 Mar 2012 19:31:33 +0000 (UTC) Received: by wgbds11 with SMTP id ds11so1581086wgb.1 for ; Mon, 05 Mar 2012 11:31:33 -0800 (PST) Received: by 10.180.84.170 with SMTP id a10mr13930825wiz.9.1330975892950; Mon, 05 Mar 2012 11:31:32 -0800 (PST) Received: from rnote.ddteam.net (123-8-133-95.pool.ukrtel.net. [95.133.8.123]) by mx.google.com with ESMTPS id ep17sm21688666wid.2.2012.03.05.11.31.30 (version=SSLv3 cipher=OTHER); Mon, 05 Mar 2012 11:31:31 -0800 (PST) Date: Mon, 5 Mar 2012 21:30:48 +0200 From: Aleksandr Rybalko To: Warner Losh , Adrian Chadd Message-Id: <20120305213048.4999b5a1.ray@ddteam.net> In-Reply-To: <4996D1CF-25E5-4422-996C-DF23B5C10732@bsdimp.com> References: <20120131213857.86c81626.ray@ddteam.net> <20120210110243.GA2012@lor.one-eyed-alien.net> <4996D1CF-25E5-4422-996C-DF23B5C10732@bsdimp.com> X-Mailer: Sylpheed 3.1.2 (GTK+ 2.24.5; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmSOsag1N406ZRGXxzrnsGJnEU799FHVP8ar/QjNae6kLsl9U0mzLX7/a+Uqnd7x/Wphi5f Cc: Brooks Davis , freebsd-arch@FreeBSD.org Subject: suspend/resume + Re: dynamic attach of hinted devices X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 19:31:34 -0000 Changing subject because now it will affect suspend/resume thread. On Fri, 10 Feb 2012 09:45:48 -0700 Warner Losh wrote: > > On Feb 10, 2012, at 4:02 AM, Brooks Davis wrote: > > > On Tue, Jan 31, 2012 at 09:38:57PM +0200, Aleksandr Rybalko wrote: > >> Hi FreeBSD hackers, > >> > >> at first I want to say this: :) > >> WARNING: FOLLOWING DEVCTL PATCH MAY EASILY PANIC YOUR SYSTEM, > >> PLEASE DO NOT TRY IT ON PRODUCTION SERVERS AND TRY IT WITH > >> FILESYSTEMS MOUNTED AS READONLY :))))) > >> > >> So I introduce two patches first one [1] used to migrate from > >> static_hints or hints in the static_kenv to dynamic hints. > >> > >> sysctl kern.hintmode=2 will copy hints from static hints or from > >> static kenv and put it into dynamic kenv. Those will allow to > >> manipulate hints values and attach hinted devices with devctl tool. > >> > >> Second [2] allow attach/detach devices with userland tool devctl. > >> > >> devctl tool allow add and initialize new devices which is not able > >> to be autoenumerating, such a hinted devices. > >> > >> Both designed to have ability update EEPROM items in runtime, since > >> some device can't work in mode when it accessible like a EEPROM > >> chip. > >> > >> Example: > >> # sysctl kern.hintmode=2 > >> # kenv hint.mx25l.0.at="spibus0" > >> # kenv hint.mx25l.0.cs=0 > >> # kenv hint.mx25l.0.chipname="at25128" > >> # devctl hinted spibus 0 mx25l 0 > >> mx25l0: at cs 0 mode 0 on spibus0 > >> mx25l0: at25128, sector 64 bytes, 256 sectors > >> GEOM: new disk flash/spi0 > >> > >> Someone may found it also useful for testing device attach/detach > >> code (memory leaks, resource allocation, etc). > >> > >> So, say me please your opinion. > > > > I skimmed over the patch and the concept looks good to me. I'm > > probably not the right person to review this proposal in detail, > > but perhaps John Baldwin (cc'd) could do it or suggest someone. > > I've looked at it and it looks OK, but I had lots of feedback I > didn't have time to write up. I like the concept, but have lots of > suggestions for improvement since I'd like to see this more > generically done. > > Warner Think this version will cover another few items from your suggestion list, Warner. :) Now devctl able to do also DEVICE_SHUTDOWN, DEVICE_SUSPEND and DEVICE_RESUME, so folks who want to test suspend/resume ability can do it easy, but of course without real device power-off. Link: http://my.ddteam.net/files/2012-03-05_devctl2.patch Another one thing to dial is a name of device. now it is /dev/devctl2, just because /dev/devctl used by devd (which not control, but just listen for device events). So we can use: 1. synonym like /dev/devmng, or 2. teach devd to do ioctl over /dev/devctl Second have another list of problems. devd is a single tool wrote in C++ used for embedded firmwares, so I replace it with simplified analogue (cdevd) to not hold c++ libs. and then, of course, much more works and bigger complexity. Hope many hackers say me own opinion :) P.S. patch is not subject to commit, but only for peoples who want to test it. When I will prepare it to commit, I will do it in 3 parts: 1. kern/subr_hints 2. kern/subr_bus + sys/bus.h + conf/options 3. sbin/devctl WBW -- Aleksandr Rybalko From owner-freebsd-arch@FreeBSD.ORG Tue Mar 6 20:07:41 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D9409106566B; Tue, 6 Mar 2012 20:07:41 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id EF2E48FC1D; Tue, 6 Mar 2012 20:07:40 +0000 (UTC) Received: by bkcjc3 with SMTP id jc3so6170564bkc.13 for ; Tue, 06 Mar 2012 12:07:39 -0800 (PST) Received-SPF: pass (google.com: domain of asmrookie@gmail.com designates 10.112.10.41 as permitted sender) client-ip=10.112.10.41; Authentication-Results: mr.google.com; spf=pass (google.com: domain of asmrookie@gmail.com designates 10.112.10.41 as permitted sender) smtp.mail=asmrookie@gmail.com; dkim=pass header.i=asmrookie@gmail.com Received: from mr.google.com ([10.112.10.41]) by 10.112.10.41 with SMTP id f9mr12025184lbb.8.1331064459761 (num_hops = 1); Tue, 06 Mar 2012 12:07:39 -0800 (PST) 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:content-type; bh=7c7TxVuV5fQtrLqX+Yf9wNa/vC+OA9Q90X91vtKsw1s=; b=bQdjm5OowhZvCjztMjC8s2l0MOuApKc5SJoTDArDfypqQ3tRV0ZLkkNUqq4VFTrT7G dv4fhPfJRamgKZDohHwSI2lPSKbQqr8tb4To1c4cVuUn4tT3c1sMouQEFmzq2EtIm1Ts ciM27GbSyYwT8enYvgRzQZvBQlQeod9AytP4Fio4iPFAZt2JeA9uLCOKUJIZUO5Cdhwn 3dECUksMIS6kGZXFOu2oR70sKTGyj5Pcf9V4zxe8wfqYzATMk4BM6BaO7uyaxks07Opj ck/TwqoX8Y84w5trhzqgcQIplTetWpgMUEkhNJjWSu9SmzGF9dDcaQ4uc1sGmg/00TYg 9bsQ== MIME-Version: 1.0 Received: by 10.112.10.41 with SMTP id f9mr9858767lbb.8.1331064459688; Tue, 06 Mar 2012 12:07:39 -0800 (PST) Sender: asmrookie@gmail.com Received: by 10.112.41.5 with HTTP; Tue, 6 Mar 2012 12:07:39 -0800 (PST) In-Reply-To: <201203062001.q26K1Q7R055245@svn.freebsd.org> References: <201203062001.q26K1Q7R055245@svn.freebsd.org> Date: Tue, 6 Mar 2012 20:07:39 +0000 X-Google-Sender-Auth: kp6NxKA7YxMGX8_xFkoKKM8tvuA Message-ID: From: Attilio Rao To: FreeBSD Arch , "freebsd-current@freebsd.org" , FreeBSD FS Content-Type: text/plain; charset=UTF-8 Cc: Subject: Re: svn commit: r232619 - in head: . sys/amd64/conf sys/arm/conf sys/i386/conf sys/ia64/conf sys/mips/conf sys/pc98/conf sys/powerpc/conf sys/sparc64/conf X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 20:07:41 -0000 2012/3/6, Attilio Rao : > Author: attilio > Date: Tue Mar 6 20:01:25 2012 > New Revision: 232619 > URL: http://svn.freebsd.org/changeset/base/232619 > > Log: > Disable the option VFS_ALLOW_NONMPSAFE by default on all the supported > platforms. > This will make every attempt to mount a non-mpsafe filesystem to the > kernel forbidden, unless it is expressely compiled with > VFS_ALLOW_NONMPSAFE option. This is just a gentle reminder in order to point you further to the "official" page: http://wiki.freebsd.org/NONMPSAFE_DEORBIT_VFS and to mention that the time for removing non-mpsafe filesystem is approaching. In 6 months we will disconnect from the tree the non-mpsafe filesystems and will remove the whole non-mpsafe handling infrastructure in the VFS and the buffer cache, thus please think about stepping up and convert your favourite filesystem. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-arch@FreeBSD.ORG Tue Mar 6 21:03:06 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 68522106566B; Tue, 6 Mar 2012 21:03:06 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from noop.in-addr.com (mail.in-addr.com [IPv6:2001:470:8:162::1]) by mx1.freebsd.org (Postfix) with ESMTP id 304618FC0C; Tue, 6 Mar 2012 21:03:06 +0000 (UTC) Received: from gjp by noop.in-addr.com with local (Exim 4.77 (FreeBSD)) (envelope-from ) id 1S51Ww-00011k-7w; Tue, 06 Mar 2012 16:02:46 -0500 Date: Tue, 6 Mar 2012 16:02:46 -0500 From: Gary Palmer To: Attilio Rao Message-ID: <20120306210246.GA80168@in-addr.com> References: <201203062001.q26K1Q7R055245@svn.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: gpalmer@freebsd.org X-SA-Exim-Scanned: No (on noop.in-addr.com); SAEximRunCond expanded to false Cc: FreeBSD FS , FreeBSD Arch , "freebsd-current@freebsd.org" Subject: Re: svn commit: r232619 - in head: . sys/amd64/conf sys/arm/conf sys/i386/conf sys/ia64/conf sys/mips/conf sys/pc98/conf sys/powerpc/conf sys/sparc64/conf X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 21:03:06 -0000 On Tue, Mar 06, 2012 at 08:07:39PM +0000, Attilio Rao wrote: > 2012/3/6, Attilio Rao : > > Author: attilio > > Date: Tue Mar 6 20:01:25 2012 > > New Revision: 232619 > > URL: http://svn.freebsd.org/changeset/base/232619 > > > > Log: > > Disable the option VFS_ALLOW_NONMPSAFE by default on all the supported > > platforms. > > This will make every attempt to mount a non-mpsafe filesystem to the > > kernel forbidden, unless it is expressely compiled with > > VFS_ALLOW_NONMPSAFE option. > > This is just a gentle reminder in order to point you further to the > "official" page: > http://wiki.freebsd.org/NONMPSAFE_DEORBIT_VFS > > and to mention that the time for removing non-mpsafe filesystem is approaching. > In 6 months we will disconnect from the tree the non-mpsafe > filesystems and will remove the whole non-mpsafe handling > infrastructure in the VFS and the buffer cache, thus please think > about stepping up and convert your favourite filesystem. Given that the wiki page still has: > Technical notes on locking Filesystems > > TBD it would be useful to people who aren't filesystem locking experts to have a little more information on the wiki Thanks, Gary From owner-freebsd-arch@FreeBSD.ORG Fri Mar 9 21:36:50 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C792106566C for ; Fri, 9 Mar 2012 21:36:50 +0000 (UTC) (envelope-from rmh.aybabtu@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 37A1A8FC12 for ; Fri, 9 Mar 2012 21:36:49 +0000 (UTC) Received: by iahk25 with SMTP id k25so3596580iah.13 for ; Fri, 09 Mar 2012 13:36:48 -0800 (PST) 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=pOsnFkoUpXViJHXccWQT4BH2unQQQm4WdbV13h5Znaw=; b=T1GjqoczQWcyhN7A9ZUhOd1ecNKIn9gTsv3rwn22g4DOu3XiJCY6J0AvY6VzMP3gf/ eGqfOzPcgyNDkcMwbNPWgQDNJEgmyuaUFpQpgr6AQx1hr0drPiFMeDsR2D+CSbCPjvr1 VSFuyDyNsZNa6i5WljW8AeWGpR0/Gw0tNkrvOtFWNA0sTW/3i8Y5sEa/jb54y49BEHJl bOtqRC1BquqZvUP5RPInt/n7n+kXok/4BeEHSnj0f27JNh+GP9B/zvY8/abye9BfNsf5 06tRVSDR3MqsnUURaXOPEgNpxPQQR64OMHhBjhh04R/SvFFDbypPByfZ2DiOMZEm+V2n 32ZA== MIME-Version: 1.0 Received: by 10.50.156.196 with SMTP id wg4mr5757123igb.13.1331329008784; Fri, 09 Mar 2012 13:36:48 -0800 (PST) Sender: rmh.aybabtu@gmail.com Received: by 10.43.130.201 with HTTP; Fri, 9 Mar 2012 13:36:48 -0800 (PST) Date: Fri, 9 Mar 2012 22:36:48 +0100 X-Google-Sender-Auth: KrceDpBcIIqN2zylQpDGIww-Rg4 Message-ID: From: Robert Millan To: freebsd-arch@freebsd.org Content-Type: multipart/mixed; boundary=e89a8f3baf01a5d70304bad630a5 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: [PATCH] Add compatibility X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 21:36:50 -0000 --e89a8f3baf01a5d70304bad630a5 Content-Type: text/plain; charset=UTF-8 This patch adds a compatibility that would make it easier to build on FreeBSD software that has been written for glibc (see example1.c). The functionality in is more or less equivalent to but provides some declarations which are incompatible with those in . One of these cases is very unfortunate because it alters I/O semantics, it applies to outb(), outw() and outl(): FreeBSD code: outw(port, data); Glibc code: outw(data, port); The undefined I/O behaviour that could potentially result from this is very scary. Because of this I've written a few checks to prevent both headers from being used at the same time. Overall, aside from the portability benefit, my proposed addition has some less obvious side-effects: Desireable side-effect: Adding would break buildability of code that attempts to use both headers at the same time _WITHOUT_ changing the outw() call semantics (see example2.c). Undesireable side-effect: Adding would break buildability of code that attempts to use both headers at the same time, and was otherwise fine due to conditionalized outw() calls (see example3.c [1]). [1] I found a real case where this happens, in sane-backends-1.0.22/backend/umax_pp_low.c. In case my patch is accepted, I commit to provide a fix for sane-backends and also to adjust Debian GNU/kFreeBSD headers to follow the same route [2]. [2] This means: reenable outb(), outw() and outl() in . Currently we provide both headers, but outb(), outw() and outl() are entirely disabled. I think it's better for both projects to provide since the majority of code out there is written with GNU/Linux in mind. Attached patch is tested against HEAD with "make universe". -- Robert Millan --e89a8f3baf01a5d70304bad630a5 Content-Type: text/plain; charset=US-ASCII; name="io.diff" Content-Disposition: attachment; filename="io.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gzlqvrlg0 SW5kZXg6IHN5cy9hbWQ2NC9pbmNsdWRlL2NwdWZ1bmMuaAo9PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMvYW1k NjQvaW5jbHVkZS9jcHVmdW5jLmgJKHJldmlzaW9uIDIzMjQwNCkKKysrIHN5cy9hbWQ2NC9pbmNs dWRlL2NwdWZ1bmMuaAkod29ya2luZyBjb3B5KQpAQCAtMzYsNiArMzYsMTAgQEAKICAqIHVzZWQg aW4gcHJlZmVyZW5jZSB0byB0aGlzLgogICovCiAKKyNpZmRlZiBfU1lTX0lPX0hfCisjZXJyb3Ig ZGVmaW5pdGlvbnMgaW4gdGhpcyBmaWxlIGNvbmZsaWN0IHdpdGggdGhvc2UgaW4gc3lzL2lvLmgK KyNlbmRpZgorCiAjaWZuZGVmIF9NQUNISU5FX0NQVUZVTkNfSF8KICNkZWZpbmUJX01BQ0hJTkVf Q1BVRlVOQ19IXwogCkluZGV4OiBzeXMvaTM4Ni9pbmNsdWRlL2NwdWZ1bmMuaAo9PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 Ci0tLSBzeXMvaTM4Ni9pbmNsdWRlL2NwdWZ1bmMuaAkocmV2aXNpb24gMjMyNDA0KQorKysgc3lz L2kzODYvaW5jbHVkZS9jcHVmdW5jLmgJKHdvcmtpbmcgY29weSkKQEAgLTM1LDYgKzM1LDEwIEBA CiAgKiB1c2VkIGluIHByZWZlcmVuY2UgdG8gdGhpcy4KICAqLwogCisjaWZkZWYgX1NZU19JT19I XworI2Vycm9yIGRlZmluaXRpb25zIGluIHRoaXMgZmlsZSBjb25mbGljdCB3aXRoIHRob3NlIGlu IHN5cy9pby5oCisjZW5kaWYKKwogI2lmbmRlZiBfTUFDSElORV9DUFVGVU5DX0hfCiAjZGVmaW5l CV9NQUNISU5FX0NQVUZVTkNfSF8KIApJbmRleDogc3lzL3N5cy9pby5oCj09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0t IHN5cy9zeXMvaW8uaAkocmV2aXNpb24gMCkKKysrIHN5cy9zeXMvaW8uaAkocmV2aXNpb24gMCkK QEAgLTAsMCArMSw1OCBAQAorLyotCisgKiBDb3B5cmlnaHQgKGMpIDIwMTIgUm9iZXJ0IE1pbGxh bgorICoKKyAqIFJlZGlzdHJpYnV0aW9uIGFuZCB1c2UgaW4gc291cmNlIGFuZCBiaW5hcnkgZm9y bXMsIHdpdGggb3Igd2l0aG91dAorICogbW9kaWZpY2F0aW9uLCBhcmUgcGVybWl0dGVkIHByb3Zp ZGVkIHRoYXQgdGhlIGZvbGxvd2luZyBjb25kaXRpb25zCisgKiBhcmUgbWV0OgorICogMS4gUmVk aXN0cmlidXRpb25zIG9mIHNvdXJjZSBjb2RlIG11c3QgcmV0YWluIHRoZSBhYm92ZSBjb3B5cmln aHQKKyAqICAgIG5vdGljZSwgdGhpcyBsaXN0IG9mIGNvbmRpdGlvbnMgYW5kIHRoZSBmb2xsb3dp bmcgZGlzY2xhaW1lci4KKyAqIDIuIFJlZGlzdHJpYnV0aW9ucyBpbiBiaW5hcnkgZm9ybSBtdXN0 IHJlcHJvZHVjZSB0aGUgYWJvdmUgY29weXJpZ2h0CisgKiAgICBub3RpY2UsIHRoaXMgbGlzdCBv ZiBjb25kaXRpb25zIGFuZCB0aGUgZm9sbG93aW5nIGRpc2NsYWltZXIgaW4gdGhlCisgKiAgICBk b2N1bWVudGF0aW9uIGFuZC9vciBvdGhlciBtYXRlcmlhbHMgcHJvdmlkZWQgd2l0aCB0aGUgZGlz dHJpYnV0aW9uLgorICoKKyAqIFRISVMgU09GVFdBUkUgSVMgUFJPVklERUQgQlkgVEhFIEFVVEhP UiBBTkQgQ09OVFJJQlVUT1JTIGBgQVMgSVMnJyBBTkQKKyAqIEFOWSBFWFBSRVNTIE9SIElNUExJ RUQgV0FSUkFOVElFUywgSU5DTFVESU5HLCBCVVQgTk9UIExJTUlURUQgVE8sIFRIRQorICogSU1Q TElFRCBXQVJSQU5USUVTIE9GIE1FUkNIQU5UQUJJTElUWSBBTkQgRklUTkVTUyBGT1IgQSBQQVJU SUNVTEFSIFBVUlBPU0UKKyAqIEFSRSBESVNDTEFJTUVELiAgSU4gTk8gRVZFTlQgU0hBTEwgVEhF IEFVVEhPUiBPUiBDT05UUklCVVRPUlMgQkUgTElBQkxFCisgKiBGT1IgQU5ZIERJUkVDVCwgSU5E SVJFQ1QsIElOQ0lERU5UQUwsIFNQRUNJQUwsIEVYRU1QTEFSWSwgT1IgQ09OU0VRVUVOVElBTAor ICogREFNQUdFUyAoSU5DTFVESU5HLCBCVVQgTk9UIExJTUlURUQgVE8sIFBST0NVUkVNRU5UIE9G IFNVQlNUSVRVVEUgR09PRFMKKyAqIE9SIFNFUlZJQ0VTOyBMT1NTIE9GIFVTRSwgREFUQSwgT1Ig UFJPRklUUzsgT1IgQlVTSU5FU1MgSU5URVJSVVBUSU9OKQorICogSE9XRVZFUiBDQVVTRUQgQU5E IE9OIEFOWSBUSEVPUlkgT0YgTElBQklMSVRZLCBXSEVUSEVSIElOIENPTlRSQUNULCBTVFJJQ1QK KyAqIExJQUJJTElUWSwgT1IgVE9SVCAoSU5DTFVESU5HIE5FR0xJR0VOQ0UgT1IgT1RIRVJXSVNF KSBBUklTSU5HIElOIEFOWSBXQVkKKyAqIE9VVCBPRiBUSEUgVVNFIE9GIFRISVMgU09GVFdBUkUs IEVWRU4gSUYgQURWSVNFRCBPRiBUSEUgUE9TU0lCSUxJVFkgT0YKKyAqIFNVQ0ggREFNQUdFLgor ICoKKyAqICRGcmVlQlNEJAorICovCisKKy8qCisgKiBUaGlzIGZpbGUgcHJvdmlkZXMgY29tcGF0 aWJpbGl0eSBnbHVlIGZvciBjb2RlIHRoYXQgZXhwZWN0cyBHTlUtc3R5bGUKKyAqIHN5cy9pby5o LiBDb2RlIHdyaXR0ZW4gZm9yIEZyZWVCU0Qgc2hvdWxkIHVzZSBzeXMvc3lzdG0uaCBpbnN0ZWFk LgorICovCisKKyNpZmRlZiBfTUFDSElORV9DUFVGVU5DX0hfCisjZXJyb3IgZGVmaW5pdGlvbnMg aW4gdGhpcyBmaWxlIGNvbmZsaWN0IHdpdGggdGhvc2UgaW4gbWFjaGluZS9jcHVmdW5jLmgKKyNl bmRpZgorCisjaWZuZGVmIF9TWVNfSU9fSF8KKworI2lmICFkZWZpbmVkKF9faTM4Nl9fKSAmJiAh ZGVmaW5lZChfX2FtZDY0X18pCisjZXJyb3IgdGhpcyBmaWxlIGlzIG9ubHkgdXNlZnVsIG9uIGkz ODYgYW5kIGFtZDY0CisjZW5kaWYKKworI2luY2x1ZGUgPHN5cy9jZGVmcy5oPgorCisjZGVmaW5l IG91dGIJYnNkX291dGIKKyNkZWZpbmUgb3V0dwlic2Rfb3V0dworI2RlZmluZSBvdXRsCWJzZF9v dXRsCisjaW5jbHVkZSA8bWFjaGluZS9jcHVmdW5jLmg+CisjdW5kZWYgb3V0YgorI3VuZGVmIG91 dHcKKyN1bmRlZiBvdXRsCisKKyNkZWZpbmUgb3V0YihkYXRhLHBvcnQpCQlic2Rfb3V0Yihwb3J0 LGRhdGEpCisjZGVmaW5lIG91dHcoZGF0YSxwb3J0KQkJYnNkX291dHcocG9ydCxkYXRhKQorI2Rl ZmluZSBvdXRsKGRhdGEscG9ydCkJCWJzZF9vdXRsKHBvcnQsZGF0YSkKKworI2RlZmluZSBfU1lT X0lPX0hfCisjZW5kaWYgLyogIV9TWVNfSU9fSF8gKi8K --e89a8f3baf01a5d70304bad630a5-- From owner-freebsd-arch@FreeBSD.ORG Fri Mar 9 22:01:26 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F982106566C; Fri, 9 Mar 2012 22:01:26 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id D760B8FC12; Fri, 9 Mar 2012 22:01:25 +0000 (UTC) Received: by dald2 with SMTP id d2so2149418dal.13 for ; Fri, 09 Mar 2012 14:01:25 -0800 (PST) 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=CRbO6Xgv53Z4LVR6eZFYPRkbWbWPPpagtOTMpNPs2Z8=; b=W5k3YkX+V9k21RUjshs4h6yx8/vu1lRlO2N5o+QdHEhyLzHZS8m9IyLtrvCI3mHRxn c3NixirvuxtoYGaVQt5F8aSNT95NXtJiTeyHFPRGdZqGvdlcuF/8hK46HJwiomn5hgjw D5Q60ZLSuAe5SgIx8J9Q3F9ZSPTX00FF2S6jKRSxeLiinoz007y/FkhlAk9Gqir9dA6n 0EOBgOoKXBbT5KOIL2M3VYhmZ5aXxPvgLPc69zztgjG5WMWOiJ9MuVXW4+3834XxBW/3 81JWM0HqmlLotM+K91NlZL0esspuVp3hS0P4V21suAfw9PtAdjYi7BqDk6aLbOOL9iJe g+Tg== MIME-Version: 1.0 Received: by 10.68.233.65 with SMTP id tu1mr6873865pbc.18.1331330485712; Fri, 09 Mar 2012 14:01:25 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.143.33.5 with HTTP; Fri, 9 Mar 2012 14:01:25 -0800 (PST) In-Reply-To: References: Date: Fri, 9 Mar 2012 14:01:25 -0800 X-Google-Sender-Auth: sA4oZn2zluphuWgsoRDPVZZ_tws Message-ID: From: Adrian Chadd To: Robert Millan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-arch@freebsd.org Subject: Re: [PATCH] Add compatibility X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 22:01:26 -0000 I really, really don't like the idea of having the same function have different argument orders based on the include file you're using. That will lead to all kinds of weird ass debugging issues later on. Why is it that we can't fix the upstream code? Adrian On 9 March 2012 13:36, Robert Millan wrote: > This patch adds a compatibility that would make it easier > to build on FreeBSD software that has been written for glibc (see > example1.c). > > The functionality in is more or less equivalent to > but provides some declarations which are > incompatible with those in . One of these cases is > very unfortunate because it alters I/O semantics, it applies to > outb(), outw() and outl(): > > =A0FreeBSD code: outw(port, data); > =A0Glibc code: outw(data, port); > > The undefined I/O behaviour that could potentially result from this is > very scary. Because of this I've written a few checks to prevent both > headers from being used at the same time. Overall, aside from the > portability benefit, my proposed addition has some less obvious > side-effects: > > =A0 =A0 Desireable side-effect: Adding would break > buildability of code that attempts to use both headers at the same > time _WITHOUT_ changing the outw() call semantics (see example2.c). > > =A0 =A0 Undesireable side-effect: Adding would break > buildability of code that attempts to use both headers at the same > time, and was otherwise fine due to conditionalized outw() calls (see > example3.c [1]). > > [1] I found a real case where this happens, in > sane-backends-1.0.22/backend/umax_pp_low.c. In case my patch is > accepted, I commit to provide a fix for sane-backends and also to > adjust Debian GNU/kFreeBSD headers to follow the same route [2]. > > [2] This means: reenable outb(), outw() and outl() in > . Currently we provide both headers, but outb(), > outw() and outl() are entirely disabled. I think it's better for both > projects to provide since the majority of code out there is > written with GNU/Linux in mind. > > Attached patch is tested against HEAD with "make universe". > > -- > Robert Millan > > _______________________________________________ > 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 Fri Mar 9 22:54:35 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 91A94106566B for ; Fri, 9 Mar 2012 22:54:35 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay04.stack.nl [IPv6:2001:610:1108:5010::107]) by mx1.freebsd.org (Postfix) with ESMTP id 0F8618FC1F for ; Fri, 9 Mar 2012 22:54:35 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id BA03E1DD5BC; Fri, 9 Mar 2012 23:54:33 +0100 (CET) Received: by snail.stack.nl (Postfix, from userid 1677) id 8F5A828470; Fri, 9 Mar 2012 23:54:33 +0100 (CET) Date: Fri, 9 Mar 2012 23:54:33 +0100 From: Jilles Tjoelker To: Matthew Story Message-ID: <20120309225433.GA32725@stack.nl> 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 Subject: Re: Change to xargs to avoid orphaning of utility processes on signal|exit 255 from child X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 22:54:35 -0000 On Tue, Feb 21, 2012 at 12:50:19PM -0500, Matthew Story wrote: > On Thu, Feb 16, 2012 at 7:09 PM, Matthew Story wrote: > > Apologies if this is the wrong list, I would like to submit a patch that > > changes the behavior of xargs(1) on signal to child utility process or > > child utility process exiting 255. The patch(es) is|are available here: > > http://axe0.blackskyresearch.net/patches/matt/xargs.no_orphan.patch.txt-- this version will apply to current xargs, and adds diagnostic > > information for exit 255|signal to utility, as required by POSIX (see > > PR165155). > > > > http://axe0.blackskyresearch.net/patches/matt/xargs.no_orphan.PR165155.patch.txt-- this version will apply on top of the patch in PR165155, as the errx > > calls in that patch need to be modified to warnx calls. > I have updated these 2 patches above to branch correctly (the change from > errx to warnx requires else'ing ... may have to purge browser catch to pick > up the change), wondering if this patch should be expanded to include all > of the cases mentioned in the ``Consequences of Errors'' section of the > POSIX specification: > > [... snip] > > If a command line meeting the specified requirements cannot be assembled, > > the utility cannot be invoked, an invocation of the utility is terminated > > by a signal, or an invocation of the utility exits with exit status 255, > > the *xargs* utility shall write a diagnostic message and exit without > > processing any remaining input. > This would cause xargs to wait on children if the command line cannot be > assembled, or utility cannot be invoked, in addition to the 2 cases covered > by the patch. This should leave termination via signal to the xargs > process itself as the only outstanding case where xargs orphans utilities, > which is congruent with sh(1) behavior, and still allows for signaling all > processes via signal to the process group, if you actually desire to signal > all utility processes, along with xargs itself. Thoughts? I think that makes sense. I updated the patch to the recent changes in -current and changed a local from short to int: Index: xargs.1 =================================================================== --- xargs.1 (revision 232399) +++ xargs.1 (working copy) @@ -297,14 +297,18 @@ The .Nm utility exits immediately (without processing any further input) if a -command line cannot be assembled, +command line cannot be assembled, or .Ar utility -cannot be invoked, an invocation of +cannot be invoked. If an invocation of .Ar utility is terminated by a signal, or an invocation of .Ar utility -exits with a value of 255. +exits with a value of 255, the +.Nm +utility stops processing input and exits after all invocations of +.Ar utility +finish processing. .Sh EXIT STATUS The .Nm Index: xargs.c =================================================================== --- xargs.c (revision 232399) +++ xargs.c (working copy) @@ -597,6 +597,7 @@ { pid_t pid; int status; + int cause_exit = 0; while ((pid = xwait(waitall || pids_full(), &status)) > 0) { /* If we couldn't invoke the utility, exit. */ @@ -604,15 +605,27 @@ errno = childerr; err(errno == ENOENT ? 127 : 126, "%s", name); } - if (WIFSIGNALED(status)) - errx(1, "%s: terminated with signal %d; aborting", + /* + * If utility exited because of a signal or with a value of + * 255, warn (per POSIX), and then wait until all other + * children have exited before exiting 1-125. POSIX requires + * xargs to stop reading if child exits because of a signal or + * with 255, but it does not require us to exit immediately; + * waiting is preferable to orphaning. + */ + if (WIFSIGNALED(status)) { + waitall = cause_exit = 1; + warnx("%s: terminated with signal %d; aborting", name, WTERMSIG(status)); - if (WEXITSTATUS(status) == 255) - errx(1, "%s: exited with status 255; aborting", name); - if (WEXITSTATUS(status)) + } else if (WEXITSTATUS(status) == 255) { + waitall = cause_exit = 1; + warnx("%s: exited with status 255; aborting", name); + } else if (WEXITSTATUS(status)) rval = 1; } + if (cause_exit) + exit(1); if (pid == -1 && errno != ECHILD) err(1, "waitpid"); } -- Jilles Tjoelker From owner-freebsd-arch@FreeBSD.ORG Fri Mar 9 23:13:30 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2AB99106564A for ; Fri, 9 Mar 2012 23:13:30 +0000 (UTC) (envelope-from matthewstory@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id CCC528FC0A for ; Fri, 9 Mar 2012 23:13:29 +0000 (UTC) Received: by vcmm1 with SMTP id m1so2325815vcm.13 for ; Fri, 09 Mar 2012 15:13:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Nhd9oRfV6e4UmBDHkNlIkuGeicPH7/vU4xw+V3vBUgI=; b=j4Jzhvr+EtI9/6u4rTp2+4Y4/hmmf+c50qR8rwZJpP6ViE4JphvnR0Pd1dqLQbmBVm VK+5RPpkH2vQavsRgNTeExt3fvASq3UZZkKA8vX9xkPtpnA4nOC62iAmuYqvFLKGsg8/ gI408OPlOywpQNr/zWxmBXO2VxA1bmdTxqi/5Coi8epAmYDLrzei517Gx/x/q8GLJBoA bbsLfe0lLBLNZrnvzkB5BI66fRIKGtUidimhwm0NOb3BcTPWdLX8kg/r93CwmXphC6ir EJlT+Q4xRr3N9dADABOUkOOF6JqCFJ5fnj5RoyN0zVWZrf3PXsBwB6GUC5yo/49forhd ZJzw== MIME-Version: 1.0 Received: by 10.52.27.111 with SMTP id s15mr6516887vdg.120.1331334803519; Fri, 09 Mar 2012 15:13:23 -0800 (PST) Received: by 10.52.93.42 with HTTP; Fri, 9 Mar 2012 15:13:23 -0800 (PST) In-Reply-To: <20120309225433.GA32725@stack.nl> References: <20120309225433.GA32725@stack.nl> Date: Fri, 9 Mar 2012 18:13:23 -0500 Message-ID: From: Matthew Story To: freebsd-arch@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Jilles Tjoelker Subject: Re: Change to xargs to avoid orphaning of utility processes on signal|exit 255 from child X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 23:13:30 -0000 On Fri, Mar 9, 2012 at 5:54 PM, Jilles Tjoelker wrote: > On Tue, Feb 21, 2012 at 12:50:19PM -0500, Matthew Story wrote: > > On Thu, Feb 16, 2012 at 7:09 PM, Matthew Story >wrote: > > > Apologies if this is the wrong list, I would like to submit a patch > that > > > changes the behavior of xargs(1) on signal to child utility process or > > > child utility process exiting 255. The patch(es) is|are available > here: > > > > > http://axe0.blackskyresearch.net/patches/matt/xargs.no_orphan.patch.txt--this version will apply to current xargs, and adds diagnostic > > > information for exit 255|signal to utility, as required by POSIX (see > > > PR165155). > > > > > > > http://axe0.blackskyresearch.net/patches/matt/xargs.no_orphan.PR165155.patch.txt--this version will apply on top of the patch in PR165155, as the errx > > > calls in that patch need to be modified to warnx calls. > > > I have updated these 2 patches above to branch correctly (the change from > > errx to warnx requires else'ing ... may have to purge browser catch to > pick > > up the change), wondering if this patch should be expanded to include all > > of the cases mentioned in the ``Consequences of Errors'' section of the > > POSIX specification: > > > > [... snip] > > > If a command line meeting the specified requirements cannot be > assembled, > > > the utility cannot be invoked, an invocation of the utility is > terminated > > > by a signal, or an invocation of the utility exits with exit status > 255, > > > the *xargs* utility shall write a diagnostic message and exit without > > > processing any remaining input. > > > This would cause xargs to wait on children if the command line cannot be > > assembled, or utility cannot be invoked, in addition to the 2 cases > covered > > by the patch. This should leave termination via signal to the xargs > > process itself as the only outstanding case where xargs orphans > utilities, > > which is congruent with sh(1) behavior, and still allows for signaling > all > > processes via signal to the process group, if you actually desire to > signal > > all utility processes, along with xargs itself. Thoughts? > > I think that makes sense. > > I updated the patch to the recent changes in -current and changed a > local from short to int: > > Index: xargs.1 > =================================================================== > --- xargs.1 (revision 232399) > +++ xargs.1 (working copy) > @@ -297,14 +297,18 @@ > The > .Nm > utility exits immediately (without processing any further input) if a > -command line cannot be assembled, > +command line cannot be assembled, or > .Ar utility > -cannot be invoked, an invocation of > +cannot be invoked. If an invocation of > .Ar utility > is terminated by a signal, > or an invocation of > .Ar utility > -exits with a value of 255. > +exits with a value of 255, the > +.Nm > +utility stops processing input and exits after all invocations of > +.Ar utility > +finish processing. > .Sh EXIT STATUS > The > .Nm > Index: xargs.c > =================================================================== > --- xargs.c (revision 232399) > +++ xargs.c (working copy) > @@ -597,6 +597,7 @@ > { > pid_t pid; > int status; > + int cause_exit = 0; > > while ((pid = xwait(waitall || pids_full(), &status)) > 0) { > /* If we couldn't invoke the utility, exit. */ > @@ -604,15 +605,27 @@ > errno = childerr; > err(errno == ENOENT ? 127 : 126, "%s", name); > } > - if (WIFSIGNALED(status)) > - errx(1, "%s: terminated with signal %d; aborting", > + /* > + * If utility exited because of a signal or with a value of > + * 255, warn (per POSIX), and then wait until all other > + * children have exited before exiting 1-125. POSIX > requires > + * xargs to stop reading if child exits because of a > signal or > + * with 255, but it does not require us to exit > immediately; > + * waiting is preferable to orphaning. > + */ > + if (WIFSIGNALED(status)) { > + waitall = cause_exit = 1; > + warnx("%s: terminated with signal %d; aborting", > name, WTERMSIG(status)); > - if (WEXITSTATUS(status) == 255) > - errx(1, "%s: exited with status 255; aborting", > name); > - if (WEXITSTATUS(status)) > + } else if (WEXITSTATUS(status) == 255) { > + waitall = cause_exit = 1; > + warnx("%s: exited with status 255; aborting", > name); > + } else if (WEXITSTATUS(status)) > rval = 1; > } > > + if (cause_exit) > + exit(1); > if (pid == -1 && errno != ECHILD) > err(1, "waitpid"); > } > changes look good to me, thanks for cleaning it up for -CURRENT. I will provide an additional patch to cover waiting for the other 2 cases (cannot assemble, or cannot invoke) later tonight after some more testing. -- regards, matt From owner-freebsd-arch@FreeBSD.ORG Sat Mar 10 04:27:25 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8CB8B1065670 for ; Sat, 10 Mar 2012 04:27:25 +0000 (UTC) (envelope-from matthewstory@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3D4178FC0A for ; Sat, 10 Mar 2012 04:27:24 +0000 (UTC) Received: by vcmm1 with SMTP id m1so2590808vcm.13 for ; Fri, 09 Mar 2012 20:27:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1hrz6cmIqaPxHex3VGNNqpwDFFNhzBR8BJOzhhd/owk=; b=LDC6PN1ViuVmPX8U52dHdCUcMEP5tPfpxAlvz/UOfWh0WwYYMfuh9syWMm0XBDdvHW QTOcx6chLbj2x/LCIVzrsPt2ZKdy2IxIgvOWjqpliilWMSNdM1TZkxEUGXBolVY5Fhab BpioJ57z1jgcROk6wQI+/OACJWREpDPaGoSRxBDpWIhNl5CWAgQbydPcTi+2pkdeFgp2 8xTyAAh+OKjjxDqeUtiAvePJjVZS0on+gujeklI4BNPVwew0NZVM17Zj9665q8gVW0gx waX9uQlin0GdA3N4U8Uot+TjBBzz33Dh3Ox+T7WXUYA0LUHbv6wr2xb/RtoKoDt9eA4q WqiQ== MIME-Version: 1.0 Received: by 10.52.34.175 with SMTP id a15mr7684941vdj.18.1331353644326; Fri, 09 Mar 2012 20:27:24 -0800 (PST) Received: by 10.52.93.42 with HTTP; Fri, 9 Mar 2012 20:27:24 -0800 (PST) In-Reply-To: References: <20120309225433.GA32725@stack.nl> Date: Fri, 9 Mar 2012 23:27:24 -0500 Message-ID: From: Matthew Story To: freebsd-arch@freebsd.org Content-Type: multipart/mixed; boundary=20cf307f33c80a601604badbed4c X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Jilles Tjoelker Subject: Re: Change to xargs to avoid orphaning of utility processes on signal|exit 255 from child X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2012 04:27:25 -0000 --20cf307f33c80a601604badbed4c Content-Type: text/plain; charset=ISO-8859-1 On Fri, Mar 9, 2012 at 6:13 PM, Matthew Story wrote: > On Fri, Mar 9, 2012 at 5:54 PM, Jilles Tjoelker wrote: > >> On Tue, Feb 21, 2012 at 12:50:19PM -0500, Matthew Story wrote: >> > On Thu, Feb 16, 2012 at 7:09 PM, Matthew Story > >wrote: >> > > Apologies if this is the wrong list, I would like to submit a patch >> that >> > > changes the behavior of xargs(1) on signal to child utility process or >> > > child utility process exiting 255. The patch(es) is|are available >> here: >> >> [...snip] >> > This would cause xargs to wait on children if the command line cannot be >> > assembled, or utility cannot be invoked, in addition to the 2 cases >> covered >> > by the patch. This should leave termination via signal to the xargs >> > > process itself as the only outstanding case where xargs orphans >> utilities, >> > which is congruent with sh(1) behavior, and still allows for signaling >> all >> > processes via signal to the process group, if you actually desire to >> signal >> > all utility processes, along with xargs itself. Thoughts? >> >> I think that makes sense. >> >> I updated the patch to the recent changes in -current and changed a >> local from short to int: >> [...snip] > > changes look good to me, thanks for cleaning it up for -CURRENT. I will > provide an additional patch to cover waiting for the other 2 cases (cannot > assemble, or cannot invoke) later tonight after some more testing. > [...snip] > I believe I have finished removing the orphan cases for the assembly failure and invocation failure cases, updated patch attached for review, also available here http://axe0.blackskyresearch.net/patches/matt/xargs.no_orphan.full.patch.txt This patch includes the cleaned-up changes Jilles sent back earlier (thanks again). -- regards, matt --20cf307f33c80a601604badbed4c Content-Type: text/plain; charset=US-ASCII; name="xargs.no_orphan.full.patch.txt" Content-Disposition: attachment; filename="xargs.no_orphan.full.patch.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gzm5kii40 SW5kZXg6IHhhcmdzLjEKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0geGFyZ3MuMQkocmV2aXNpb24gMjMyNzY0KQor KysgeGFyZ3MuMQkod29ya2luZyBjb3B5KQpAQCAtMjk0LDE3ICsyOTQsMTcgQEAKIC5BciB1dGls aXR5CiByZWFkcyBmcm9tIHRoZSBzdGFuZGFyZCBpbnB1dC4KIC5QcAotVGhlCi0uTm0KLXV0aWxp dHkgZXhpdHMgaW1tZWRpYXRlbHkgKHdpdGhvdXQgcHJvY2Vzc2luZyBhbnkgZnVydGhlciBpbnB1 dCkgaWYgYQotY29tbWFuZCBsaW5lIGNhbm5vdCBiZSBhc3NlbWJsZWQsCitJZiBhIGNvbW1hbmQg bGluZSBjYW5ub3QgYmUgYXNzZW1ibGVkLCBvcgorY2Fubm90IGJlIGludm9rZWQsIG9yIGlmIGFu IGludm9jYXRpb24gb2YKIC5BciB1dGlsaXR5Ci1jYW5ub3QgYmUgaW52b2tlZCwgYW4gaW52b2Nh dGlvbiBvZgotLkFyIHV0aWxpdHkKIGlzIHRlcm1pbmF0ZWQgYnkgYSBzaWduYWwsCiBvciBhbiBp bnZvY2F0aW9uIG9mCiAuQXIgdXRpbGl0eQotZXhpdHMgd2l0aCBhIHZhbHVlIG9mIDI1NS4KK2V4 aXRzIHdpdGggYSB2YWx1ZSBvZiAyNTUsIHRoZQorLk5tCit1dGlsaXR5IHN0b3BzIHByb2Nlc3Np bmcgaW5wdXQgYW5kIGV4aXRzIGFmdGVyIGFsbCBpbnZvY2F0aW9ucyBvZgorLkFyIHV0aWxpdHkK K2ZpbmlzaCBwcm9jZXNzaW5nLgogLlNoIEVYSVQgU1RBVFVTCiBUaGUKIC5ObQpJbmRleDogeGFy Z3MuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09Ci0tLSB4YXJncy5jCShyZXZpc2lvbiAyMzI3NjQpCisrKyB4YXJncy5j CSh3b3JraW5nIGNvcHkpCkBAIC03MCw2ICs3MCw3IEBACiBzdGF0aWMgdm9pZAl1c2FnZSh2b2lk KTsKIHZvaWQJCXN0cm5zdWJzdChjaGFyICoqLCBjb25zdCBjaGFyICosIGNvbnN0IGNoYXIgKiwg c2l6ZV90KTsKIHN0YXRpYyBwaWRfdAl4d2FpdChpbnQgYmxvY2ssIGludCAqc3RhdHVzKTsKK3N0 YXRpYyB2b2lkCXhleGl0KGNvbnN0IGNoYXIgKiwgY29uc3QgaW50KTsKIHN0YXRpYyB2b2lkCXdh aXRjaGlsZHJlbihjb25zdCBjaGFyICosIGludCk7CiBzdGF0aWMgdm9pZAlwaWRzX2luaXQodm9p ZCk7CiBzdGF0aWMgaW50CXBpZHNfZW1wdHkodm9pZCk7CkBAIC0zMDgsOCArMzA5LDEwIEBACiAJ CWNvdW50Kys7CSAgICAvKiBJbmRpY2F0ZSBlbmQtb2YtbGluZSAodXNlZCBieSAtTCkgKi8KIAog CQkvKiBRdW90ZXMgZG8gbm90IGVzY2FwZSBuZXdsaW5lcy4gKi8KLWFyZzE6CQlpZiAoaW5zaW5n bGUgfHwgaW5kb3VibGUpCi0JCQllcnJ4KDEsICJ1bnRlcm1pbmF0ZWQgcXVvdGUiKTsKK2FyZzE6 CQlpZiAoaW5zaW5nbGUgfHwgaW5kb3VibGUpIHsKKwkJCXdhcm54KCJ1bnRlcm1pbmF0ZWQgcXVv dGUiKTsKKwkJCXhleGl0KCphdiwgMSk7CisJCX0KIGFyZzI6CiAJCWZvdW5kZW9mID0gKmVvZnN0 ciAhPSAnXDAnICYmCiAJCSAgICBzdHJuY21wKGFyZ3AsIGVvZnN0ciwgcCAtIGFyZ3ApID09IDA7 CkBAIC0zNDIsOCArMzQ1LDEwIEBACiAJCQkJICovCiAJCQkJaW5wbGluZSA9IHJlYWxsb2MoaW5w bGluZSwgY3VybGVuICsgMiArCiAJCQkJICAgIHN0cmxlbihhcmdwKSk7Ci0JCQkJaWYgKGlucGxp bmUgPT0gTlVMTCkKLQkJCQkJZXJyeCgxLCAicmVhbGxvYyBmYWlsZWQiKTsKKwkJCQlpZiAoaW5w bGluZSA9PSBOVUxMKSB7CisJCQkJCXdhcm54KCJyZWFsbG9jIGZhaWxlZCIpOworCQkJCQl4ZXhp dCgqYXYsIDEpOworCQkJCX0KIAkJCQlpZiAoY3VybGVuID09IDEpCiAJCQkJCXN0cmNweShpbnBs aW5lLCBhcmdwKTsKIAkJCQllbHNlCkBAIC0zNjAsOCArMzY1LDEwIEBACiAJCSAqLwogCQlpZiAo eHAgPT0gZW5keHAgfHwgcCA+IGVicCB8fCBjaCA9PSBFT0YgfHwKIAkJICAgIChMZmxhZyA8PSBj b3VudCAmJiB4ZmxhZykgfHwgZm91bmRlb2YpIHsKLQkJCWlmICh4ZmxhZyAmJiB4cCAhPSBlbmR4 cCAmJiBwID4gZWJwKQotCQkJCWVycngoMSwgImluc3VmZmljaWVudCBzcGFjZSBmb3IgYXJndW1l bnRzIik7CisJCQlpZiAoeGZsYWcgJiYgeHAgIT0gZW5keHAgJiYgcCA+IGVicCkgeworCQkJCXdh cm54KCJpbnN1ZmZpY2llbnQgc3BhY2UgZm9yIGFyZ3VtZW50cyIpOworCQkJCXhleGl0KCphdiwg MSk7CisJCQl9CiAJCQlpZiAoamZvdW5kKSB7CiAJCQkJZm9yIChhdmogPSBhcmd2OyAqYXZqOyBh dmorKykKIAkJCQkJKnhwKysgPSAqYXZqOwpAQCAtMzk0LDggKzQwMSwxMCBAQAogCQlpZiAoemZs YWcpCiAJCQlnb3RvIGFkZGNoOwogCQkvKiBCYWNrc2xhc2ggZXNjYXBlcyBhbnl0aGluZywgaXMg ZXNjYXBlZCBieSBxdW90ZXMuICovCi0JCWlmICghaW5zaW5nbGUgJiYgIWluZG91YmxlICYmIChj aCA9IGdldGNoYXIoKSkgPT0gRU9GKQotCQkJZXJyeCgxLCAiYmFja3NsYXNoIGF0IEVPRiIpOwor CQlpZiAoIWluc2luZ2xlICYmICFpbmRvdWJsZSAmJiAoY2ggPSBnZXRjaGFyKCkpID09IEVPRikg eworCQkJd2FybngoImJhY2tzbGFzaCBhdCBFT0YiKTsKKwkJCXhleGl0KCphdiwgMSk7CisJCX0K IAkJLyogRkFMTFRIUk9VR0ggKi8KIAlkZWZhdWx0OgogYWRkY2g6CQlpZiAocCA8IGVicCkgewpA QCAtNDA0LDExICs0MTMsMTUgQEAKIAkJfQogCiAJCS8qIElmIG9ubHkgb25lIGFyZ3VtZW50LCBu b3QgZW5vdWdoIGJ1ZmZlciBzcGFjZS4gKi8KLQkJaWYgKGJ4cCA9PSB4cCkKLQkJCWVycngoMSwg Imluc3VmZmljaWVudCBzcGFjZSBmb3IgYXJndW1lbnQiKTsKKwkJaWYgKGJ4cCA9PSB4cCkgewor CQkJd2FybngoImluc3VmZmljaWVudCBzcGFjZSBmb3IgYXJndW1lbnQiKTsKKwkJCXhleGl0KCph diwgMSk7CisJCX0KIAkJLyogRGlkbid0IGhpdCBhcmd1bWVudCBsaW1pdCwgc28gaWYgeGZsYWcg b2JqZWN0LiAqLwotCQlpZiAoeGZsYWcpCi0JCQllcnJ4KDEsICJpbnN1ZmZpY2llbnQgc3BhY2Ug Zm9yIGFyZ3VtZW50cyIpOworCQlpZiAoeGZsYWcpIHsKKwkJCXdhcm54KCJpbnN1ZmZpY2llbnQg c3BhY2UgZm9yIGFyZ3VtZW50cyIpOworCQkJeGV4aXQoKmF2LCAxKTsKKwkJfQogCiAJCWlmIChq Zm91bmQpIHsKIAkJCWZvciAoYXZqID0gYXJndjsgKmF2ajsgYXZqKyspCkBAIC00NDksMTYgKzQ2 MiwyMCBAQAogCSAqIGEgTlVMTCBhdCB0aGUgdGFpbC4KIAkgKi8KIAl0bXAgPSBtYWxsb2MoKGFy Z2MgKyAxKSAqIHNpemVvZihjaGFyKiopKTsKLQlpZiAodG1wID09IE5VTEwpCi0JCWVycngoMSwg Im1hbGxvYyBmYWlsZWQiKTsKKwlpZiAodG1wID09IE5VTEwpIHsKKwkJd2FybngoIm1hbGxvYyBm YWlsZWQiKTsKKwkJeGV4aXQoKmFyZ3YsIDEpOworCX0KIAl0bXAyID0gdG1wOwogCiAJLyoKIAkg KiBTYXZlIHRoZSBmaXJzdCBhcmd1bWVudCBhbmQgaXRlcmF0ZSBvdmVyIGl0LCB3ZQogCSAqIGNh bm5vdCBkbyBzdHJuc3Vic3QoKSB0byBpdC4KIAkgKi8KLQlpZiAoKCp0bXArKyA9IHN0cmR1cCgq YXZqKyspKSA9PSBOVUxMKQotCQllcnJ4KDEsICJzdHJkdXAgZmFpbGVkIik7CisJaWYgKCgqdG1w KysgPSBzdHJkdXAoKmF2aisrKSkgPT0gTlVMTCkgeworCQl3YXJueCgic3RyZHVwIGZhaWxlZCIp OworCQl4ZXhpdCgqYXJndiwgMSk7CisJfQogCiAJLyoKIAkgKiBGb3IgZWFjaCBhcmd1bWVudCB0 byB1dGlsaXR5LCBpZiB3ZSBoYXZlIG5vdCB1c2VkIHVwCkBAIC00NzUsOCArNDkyLDEwIEBACiAJ CQlpZiAocmVwbHMgPiAwKQogCQkJCXJlcGxzLS07CiAJCX0gZWxzZSB7Ci0JCQlpZiAoKCp0bXAg PSBzdHJkdXAoKnRtcCkpID09IE5VTEwpCi0JCQkJZXJyeCgxLCAic3RyZHVwIGZhaWxlZCIpOwor CQkJaWYgKCgqdG1wID0gc3RyZHVwKCp0bXApKSA9PSBOVUxMKSB7CisJCQkJd2FybngoInN0cmR1 cCBmYWlsZWQiKTsKKwkJCQl4ZXhpdCgqYXJndiwgMSk7CisJCQl9CiAJCQl0bXArKzsKIAkJfQog CX0KQEAgLTU0Nyw3ICs1NjYsOCBAQAogCWNoaWxkZXJyID0gMDsKIAlzd2l0Y2ggKHBpZCA9IHZm b3JrKCkpIHsKIAljYXNlIC0xOgotCQllcnIoMSwgInZmb3JrIik7CisJCXdhcm4oInZmb3JrIik7 CisJCXhleGl0KCphcmd2LCAxKTsKIAljYXNlIDA6CiAJCWlmIChvZmxhZykgewogCQkJaWYgKChm ZCA9IG9wZW4oX1BBVEhfVFRZLCBPX1JET05MWSkpID09IC0xKQpAQCAtNTkzLDI2ICs2MTMsNDcg QEAKIH0KIAogc3RhdGljIHZvaWQKK3hleGl0KGNvbnN0IGNoYXIgKm5hbWUsIGNvbnN0IGludCBl eGl0X2NvZGUpIHsKKwl3YWl0Y2hpbGRyZW4obmFtZSwgMSk7CisJZXhpdChleGl0X2NvZGUpOwor fQorCitzdGF0aWMgdm9pZAogd2FpdGNoaWxkcmVuKGNvbnN0IGNoYXIgKm5hbWUsIGludCB3YWl0 YWxsKQogewogCXBpZF90IHBpZDsKIAlpbnQgc3RhdHVzOworCWludCBjYXVzZV9leGl0ID0gMDsK IAogCXdoaWxlICgocGlkID0geHdhaXQod2FpdGFsbCB8fCBwaWRzX2Z1bGwoKSwgJnN0YXR1cykp ID4gMCkgewogCQkvKiBJZiB3ZSBjb3VsZG4ndCBpbnZva2UgdGhlIHV0aWxpdHksIGV4aXQuICov CiAJCWlmIChjaGlsZGVyciAhPSAwKSB7CiAJCQllcnJubyA9IGNoaWxkZXJyOwotCQkJZXJyKGVy cm5vID09IEVOT0VOVCA/IDEyNyA6IDEyNiwgIiVzIiwgbmFtZSk7CisJCQl3YWl0YWxsID0gMTsK KwkJCWNhdXNlX2V4aXQgPSBFTk9FTlQgPyAxMjcgOiAxMjY7CisJCQl3YXJuKCIlcyIsIG5hbWUp OwogCQl9Ci0JCWlmIChXSUZTSUdOQUxFRChzdGF0dXMpKQotCQkJZXJyeCgxLCAiJXM6IHRlcm1p bmF0ZWQgd2l0aCBzaWduYWwgJWQ7IGFib3J0aW5nIiwKKwkJLyoKKwkJICogSWYgdXRpbGl0eSBl eGl0ZWQgYmVjYXVzZSBvZiBhIHNpZ25hbCBvciB3aXRoIGEgdmFsdWUgb2YKKwkJICogMjU1LCB3 YXJuIChwZXIgUE9TSVgpLCBhbmQgdGhlbiB3YWl0IHVudGlsIGFsbCBvdGhlcgorCQkgKiBjaGls ZHJlbiBoYXZlIGV4aXRlZCBiZWZvcmUgZXhpdGluZyAxLTEyNS4gUE9TSVggcmVxdWlyZXMKKwkJ ICogeGFyZ3MgdG8gc3RvcCByZWFkaW5nIGlmIGNoaWxkIGV4aXRzIGJlY2F1c2Ugb2YgYSBzaWdu YWwgb3IKKwkJICogd2l0aCAyNTUsIGJ1dCBpdCBkb2VzIG5vdCByZXF1aXJlIHVzIHRvIGV4aXQg aW1tZWRpYXRlbHk7CisJCSAqIHdhaXRpbmcgaXMgcHJlZmVyYWJsZSB0byBvcnBoYW5pbmcuCisJ CSAqLworCQlpZiAoV0lGU0lHTkFMRUQoc3RhdHVzKSkgeworCQkJd2FpdGFsbCA9IGNhdXNlX2V4 aXQgPSAxOworCQkJd2FybngoIiVzOiB0ZXJtaW5hdGVkIHdpdGggc2lnbmFsICVkOyBhYm9ydGlu ZyIsCiAJCQkgICAgbmFtZSwgV1RFUk1TSUcoc3RhdHVzKSk7Ci0JCWlmIChXRVhJVFNUQVRVUyhz dGF0dXMpID09IDI1NSkKLQkJCWVycngoMSwgIiVzOiBleGl0ZWQgd2l0aCBzdGF0dXMgMjU1OyBh Ym9ydGluZyIsIG5hbWUpOwotCQlpZiAoV0VYSVRTVEFUVVMoc3RhdHVzKSkKLQkJCXJ2YWwgPSAx OworCQl9IGVsc2UgaWYgKFdFWElUU1RBVFVTKHN0YXR1cykgPT0gMjU1KSB7CisJCQl3YWl0YWxs ID0gY2F1c2VfZXhpdCA9IDE7CisJCQl3YXJueCgiJXM6IGV4aXRlZCB3aXRoIHN0YXR1cyAyNTU7 IGFib3J0aW5nIiwgbmFtZSk7CisJCX0gZWxzZSBpZiAoV0VYSVRTVEFUVVMoc3RhdHVzKSkKKyAJ CQlydmFsID0gMTsKIAl9CiAKKyAJaWYgKGNhdXNlX2V4aXQpCisJCWV4aXQoY2F1c2VfZXhpdCk7 CiAJaWYgKHBpZCA9PSAtMSAmJiBlcnJubyAhPSBFQ0hJTEQpCiAJCWVycigxLCAid2FpdHBpZCIp OwogfQo= --20cf307f33c80a601604badbed4c-- From owner-freebsd-arch@FreeBSD.ORG Sat Mar 10 13:26:34 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BDD93106566C; Sat, 10 Mar 2012 13:26:34 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail16.syd.optusnet.com.au (mail16.syd.optusnet.com.au [211.29.132.197]) by mx1.freebsd.org (Postfix) with ESMTP id 537268FC13; Sat, 10 Mar 2012 13:26:33 +0000 (UTC) Received: from c211-30-171-136.carlnfd1.nsw.optusnet.com.au (c211-30-171-136.carlnfd1.nsw.optusnet.com.au [211.30.171.136]) by mail16.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q2ADQOWP014187 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 11 Mar 2012 00:26:26 +1100 Date: Sun, 11 Mar 2012 00:26:24 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Adrian Chadd In-Reply-To: Message-ID: <20120310232918.F1586@besplex.bde.org> References: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1475161723-1331385984=:1586" Cc: freebsd-arch@freebsd.org, Robert Millan Subject: Re: [PATCH] Add compatibility X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2012 13:26:34 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1475161723-1331385984=:1586 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Top posting. Why should I have deleted this instead of replying? On Fri, 9 Mar 2012, Adrian Chadd wrote: > I really, really don't like the idea of having the same function have > different argument orders based on the include file you're using. > > That will lead to all kinds of weird ass debugging issues later on. > > Why is it that we can't fix the upstream code? > On 9 March 2012 13:36, Robert Millan wrote: >> This patch adds a compatibility that would make it easier >> to build on FreeBSD software that has been written for glibc (see >> example1.c). I somehow missed the original mail. cpufunc.h has no user-serving parts inside, so it can't conflict with any legal include. However, abusing it in userland is convenient. Even using the port i/o functions in it in the kernel is an error. Bus space functions should be used instead. However, the i/o functions in it are much older than bus space, and abusing them in MD code in the kernel is convenient. >> The functionality in is more or less equivalent to >> but provides some declarations which are >> incompatible with those in . One of these cases is >> very unfortunate because it alters I/O semantics, it applies to >> outb(), outw() and outl(): All of it? It has many other mistakes. I doubt anything would duplicate them all :-). >> =A0FreeBSD code: outw(port, data); >> =A0Glibc code: outw(data, port); The FreeBSD order seemed natural to me since I was familiar with Intel/DOS and they never used AT&T asm order. I put the i/o functions in cpufunc.h, but 386BSD seems to have had them in the Intel order, since 4.4BSD has them in Intel order. >> The undefined I/O behaviour that could potentially result from this is >> very scary. Because of this I've written a few checks to prevent both >> headers from being used at the same time. Overall, aside from the >> portability benefit, my proposed addition has some less obvious >> side-effects: #error "no user serving parts inside" would prevent cpufunc.h being abused at any time :-). >> =A0 =A0 Desireable side-effect: Adding would break >> buildability of code that attempts to use both headers at the same >> time _WITHOUT_ changing the outw() call semantics (see example2.c). A sys header is more unsuitable, since this is very machine-dependent. Even bus space's header is not in sys (it is ), though many of its APIs are MI (with very MD internals for the typeded types). Userland has even more reasons to avoid the machine dependencies. Bus space is more complex, but seems to work OK in userland: % #include % #include %=20 % void % my_outb(unsigned int port, unsigned char data) % { % =09bus_space_write_1(X86_BUS_SPACE_IO, port, 0, data); % } This gives only minor pessimizations relative to the raw inline asm outb(). To get this to work, I had to work around the following problems: - the prerequisite is undocumented - someone renamed I386_BUS_SPACE_IO and AMD64_BUS_SPACE_IO to X86_BUS_SPACE_IO. This gives portability problems, and I only remembere= d the old names. Having the machine name in the API at all is a bug. Especially for BUS_SPACE_MEM, the machine arch can't make any difference= =2E There might be different types of memory mapped i/o, but a plain MEM sho= uld mean "ordinary" memory, or the least-extraordinary memory that the machi= ne has, or if that is too extraordinary, then just don't implement BUS_TYPE_MEM. Similarly for IO. It means port i/o for x86, and jusr including the x86 header says that you want the x86 version of "ordinary= " ports. - has undocumented namespace pollution. It includes , and even uses outb() from it. So I had to rename my function my_outb() to get it to compile. - some of the undocumented namespace pollution can be killed by the BUS_SPACE_NO_LEGACY option. This option is of course undocumented. It only kills the in/out i/o functions from , leaving all the other pollution, since it is intended for keeping bus space pure. It is poorly implemented by defining the functions as syntactically correct expressions, after undefing inb and outb since it hasn't caught up with that becoming unnecessary a couple of years ago. Anyway, this is no use for making the above compile with my_outb changed back to outb. Since the polluting outb is still in the way. Bruce --0-1475161723-1331385984=:1586-- From owner-freebsd-arch@FreeBSD.ORG Sat Mar 10 18:23:04 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0195C1065673 for ; Sat, 10 Mar 2012 18:23:04 +0000 (UTC) (envelope-from matthewstory@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id A1C948FC15 for ; Sat, 10 Mar 2012 18:23:03 +0000 (UTC) Received: by vcmm1 with SMTP id m1so3258502vcm.13 for ; Sat, 10 Mar 2012 10:23:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mwci5DH7houUP4PYiuAlTF3TNyJ9ARRPHWcMshb898A=; b=Ng7HG1GVHJRZNG+WRa0K2eZ/u2ncxnYbBmijcTs0mANrXh2amCFnx/hgi6O1vXVThz pH35Q3FCOEmSwh9z/KAm3pFnf6Rddc4ylIJOyOxJ0O8ylrHP0O3fQWOIFi/mjUu8oEEJ Pqac+hfaOuw8f7v2H48ukchw3fRDgXEwGn+7mp9n2yFV2LDAYIiIjq/116Hz1tnATBDr IbIT1oKx+Zw+VBnuUTIsfwkRmGwOrtqv1zsRIGvUzI65lM3qtecbxkfP0Jr5hLlFqbJC opkXGR6iONFOCZjH6/NC/hpowAfZMV/0k398XGhEpzkdkmf/FdfqMao7As9mOsx5Rg1I 1+xA== MIME-Version: 1.0 Received: by 10.52.93.179 with SMTP id cv19mr10209576vdb.103.1331403782911; Sat, 10 Mar 2012 10:23:02 -0800 (PST) Received: by 10.52.93.42 with HTTP; Sat, 10 Mar 2012 10:23:02 -0800 (PST) In-Reply-To: References: <20120309225433.GA32725@stack.nl> Date: Sat, 10 Mar 2012 13:23:02 -0500 Message-ID: From: Matthew Story To: freebsd-arch@freebsd.org Content-Type: multipart/mixed; boundary=20cf3071cde288766004bae7991f X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Jilles Tjoelker Subject: Re: Change to xargs to avoid orphaning of utility processes on signal|exit 255 from child X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2012 18:23:04 -0000 --20cf3071cde288766004bae7991f Content-Type: text/plain; charset=ISO-8859-1 On Fri, Mar 9, 2012 at 11:27 PM, Matthew Story wrote: > On Fri, Mar 9, 2012 at 6:13 PM, Matthew Story wrote: > >> On Fri, Mar 9, 2012 at 5:54 PM, Jilles Tjoelker wrote: >> >>> On Tue, Feb 21, 2012 at 12:50:19PM -0500, Matthew Story wrote: >>> > On Thu, Feb 16, 2012 at 7:09 PM, Matthew Story >> >wrote: >>> > > Apologies if this is the wrong list, I would like to submit a patch >>> that >>> > > changes the behavior of xargs(1) on signal to child utility process >>> or >>> > > child utility process exiting 255. The patch(es) is|are available >>> here: >>> >>> [...snip] >>> >>> > This would cause xargs to wait on children if the command line cannot >>> be >>> > assembled, or utility cannot be invoked, in addition to the 2 cases >>> covered >>> > by the patch. This should leave termination via signal to the xargs >>> >> > process itself as the only outstanding case where xargs orphans >>> utilities, >>> > which is congruent with sh(1) behavior, and still allows for signaling >>> all >>> > processes via signal to the process group, if you actually desire to >>> signal >>> > all utility processes, along with xargs itself. Thoughts? >>> >>> I think that makes sense. >>> >>> I updated the patch to the recent changes in -current and changed a >>> local from short to int: >>> [...snip] >> >> changes look good to me, thanks for cleaning it up for -CURRENT. I will >> provide an additional patch to cover waiting for the other 2 cases (cannot >> assemble, or cannot invoke) later tonight after some more testing. >> [...snip] >> > > I believe I have finished removing the orphan cases for the assembly > failure and invocation failure cases, updated patch attached for review, > also available here > > > http://axe0.blackskyresearch.net/patches/matt/xargs.no_orphan.full.patch.txt > Updated this patch (also attached), to consolidate all waitchildren, exit to use xexit, and tidied up a multiple warning condition on childerr to warn only once while waiting to exit. > > This patch includes the cleaned-up changes Jilles sent back earlier > (thanks again). > > -- > regards, > matt > -- regards, matt --20cf3071cde288766004bae7991f Content-Type: text/plain; charset=US-ASCII; name="xargs.no_orphan.full.patch.txt" Content-Disposition: attachment; filename="xargs.no_orphan.full.patch.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gzmzex3u1 SW5kZXg6IHhhcmdzLjEKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0geGFyZ3MuMQkocmV2aXNpb24gMjMyNzg3KQor KysgeGFyZ3MuMQkod29ya2luZyBjb3B5KQpAQCAtMjk0LDE3ICsyOTQsMTcgQEAKIC5BciB1dGls aXR5CiByZWFkcyBmcm9tIHRoZSBzdGFuZGFyZCBpbnB1dC4KIC5QcAotVGhlCi0uTm0KLXV0aWxp dHkgZXhpdHMgaW1tZWRpYXRlbHkgKHdpdGhvdXQgcHJvY2Vzc2luZyBhbnkgZnVydGhlciBpbnB1 dCkgaWYgYQotY29tbWFuZCBsaW5lIGNhbm5vdCBiZSBhc3NlbWJsZWQsCitJZiBhIGNvbW1hbmQg bGluZSBjYW5ub3QgYmUgYXNzZW1ibGVkLCBvcgorY2Fubm90IGJlIGludm9rZWQsIG9yIGlmIGFu IGludm9jYXRpb24gb2YKIC5BciB1dGlsaXR5Ci1jYW5ub3QgYmUgaW52b2tlZCwgYW4gaW52b2Nh dGlvbiBvZgotLkFyIHV0aWxpdHkKIGlzIHRlcm1pbmF0ZWQgYnkgYSBzaWduYWwsCiBvciBhbiBp bnZvY2F0aW9uIG9mCiAuQXIgdXRpbGl0eQotZXhpdHMgd2l0aCBhIHZhbHVlIG9mIDI1NS4KK2V4 aXRzIHdpdGggYSB2YWx1ZSBvZiAyNTUsIHRoZQorLk5tCit1dGlsaXR5IHN0b3BzIHByb2Nlc3Np bmcgaW5wdXQgYW5kIGV4aXRzIGFmdGVyIGFsbCBpbnZvY2F0aW9ucyBvZgorLkFyIHV0aWxpdHkK K2ZpbmlzaCBwcm9jZXNzaW5nLgogLlNoIEVYSVQgU1RBVFVTCiBUaGUKIC5ObQpJbmRleDogeGFy Z3MuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09Ci0tLSB4YXJncy5jCShyZXZpc2lvbiAyMzI3ODcpCisrKyB4YXJncy5j CSh3b3JraW5nIGNvcHkpCkBAIC03MCw2ICs3MCw3IEBACiBzdGF0aWMgdm9pZAl1c2FnZSh2b2lk KTsKIHZvaWQJCXN0cm5zdWJzdChjaGFyICoqLCBjb25zdCBjaGFyICosIGNvbnN0IGNoYXIgKiwg c2l6ZV90KTsKIHN0YXRpYyBwaWRfdAl4d2FpdChpbnQgYmxvY2ssIGludCAqc3RhdHVzKTsKK3N0 YXRpYyB2b2lkCXhleGl0KGNvbnN0IGNoYXIgKiwgY29uc3QgaW50KTsKIHN0YXRpYyB2b2lkCXdh aXRjaGlsZHJlbihjb25zdCBjaGFyICosIGludCk7CiBzdGF0aWMgdm9pZAlwaWRzX2luaXQodm9p ZCk7CiBzdGF0aWMgaW50CXBpZHNfZW1wdHkodm9pZCk7CkBAIC0yODAsMTAgKzI4MSw4IEBACiAJ c3dpdGNoIChjaCA9IGdldGNoYXIoKSkgewogCWNhc2UgRU9GOgogCQkvKiBObyBhcmd1bWVudHMg c2luY2UgbGFzdCBleGVjLiAqLwotCQlpZiAocCA9PSBiYnApIHsKLQkJCXdhaXRjaGlsZHJlbigq YXYsIDEpOwotCQkJZXhpdChydmFsKTsKLQkJfQorCQlpZiAocCA9PSBiYnApCisJCQl4ZXhpdCgq YXYsIHJ2YWwpOwogCQlnb3RvIGFyZzE7CiAJY2FzZSAnICc6CiAJY2FzZSAnXHQnOgpAQCAtMzA4 LDggKzMwNywxMCBAQAogCQljb3VudCsrOwkgICAgLyogSW5kaWNhdGUgZW5kLW9mLWxpbmUgKHVz ZWQgYnkgLUwpICovCiAKIAkJLyogUXVvdGVzIGRvIG5vdCBlc2NhcGUgbmV3bGluZXMuICovCi1h cmcxOgkJaWYgKGluc2luZ2xlIHx8IGluZG91YmxlKQotCQkJZXJyeCgxLCAidW50ZXJtaW5hdGVk IHF1b3RlIik7CithcmcxOgkJaWYgKGluc2luZ2xlIHx8IGluZG91YmxlKSB7CisJCQl3YXJueCgi dW50ZXJtaW5hdGVkIHF1b3RlIik7CisJCQl4ZXhpdCgqYXYsIDEpOworCQl9CiBhcmcyOgogCQlm b3VuZGVvZiA9ICplb2ZzdHIgIT0gJ1wwJyAmJgogCQkgICAgc3RybmNtcChhcmdwLCBlb2ZzdHIs IHAgLSBhcmdwKSA9PSAwOwpAQCAtMzQyLDggKzM0MywxMCBAQAogCQkJCSAqLwogCQkJCWlucGxp bmUgPSByZWFsbG9jKGlucGxpbmUsIGN1cmxlbiArIDIgKwogCQkJCSAgICBzdHJsZW4oYXJncCkp OwotCQkJCWlmIChpbnBsaW5lID09IE5VTEwpCi0JCQkJCWVycngoMSwgInJlYWxsb2MgZmFpbGVk Iik7CisJCQkJaWYgKGlucGxpbmUgPT0gTlVMTCkgeworCQkJCQl3YXJueCgicmVhbGxvYyBmYWls ZWQiKTsKKwkJCQkJeGV4aXQoKmF2LCAxKTsKKwkJCQl9CiAJCQkJaWYgKGN1cmxlbiA9PSAxKQog CQkJCQlzdHJjcHkoaW5wbGluZSwgYXJncCk7CiAJCQkJZWxzZQpAQCAtMzYwLDE3ICszNjMsMTcg QEAKIAkJICovCiAJCWlmICh4cCA9PSBlbmR4cCB8fCBwID4gZWJwIHx8IGNoID09IEVPRiB8fAog CQkgICAgKExmbGFnIDw9IGNvdW50ICYmIHhmbGFnKSB8fCBmb3VuZGVvZikgewotCQkJaWYgKHhm bGFnICYmIHhwICE9IGVuZHhwICYmIHAgPiBlYnApCi0JCQkJZXJyeCgxLCAiaW5zdWZmaWNpZW50 IHNwYWNlIGZvciBhcmd1bWVudHMiKTsKKwkJCWlmICh4ZmxhZyAmJiB4cCAhPSBlbmR4cCAmJiBw ID4gZWJwKSB7CisJCQkJd2FybngoImluc3VmZmljaWVudCBzcGFjZSBmb3IgYXJndW1lbnRzIik7 CisJCQkJeGV4aXQoKmF2LCAxKTsKKwkJCX0KIAkJCWlmIChqZm91bmQpIHsKIAkJCQlmb3IgKGF2 aiA9IGFyZ3Y7ICphdmo7IGF2aisrKQogCQkJCQkqeHArKyA9ICphdmo7CiAJCQl9CiAJCQlwcmVy dW4oYXJnYywgYXYpOwotCQkJaWYgKGNoID09IEVPRiB8fCBmb3VuZGVvZikgewotCQkJCXdhaXRj aGlsZHJlbigqYXYsIDEpOwotCQkJCWV4aXQocnZhbCk7Ci0JCQl9CisJCQlpZiAoY2ggPT0gRU9G IHx8IGZvdW5kZW9mKQorCQkJCXhleGl0KCphdiwgcnZhbCk7CiAJCQlwID0gYmJwOwogCQkJeHAg PSBieHA7CiAJCQljb3VudCA9IDA7CkBAIC0zOTQsOCArMzk3LDEwIEBACiAJCWlmICh6ZmxhZykK IAkJCWdvdG8gYWRkY2g7CiAJCS8qIEJhY2tzbGFzaCBlc2NhcGVzIGFueXRoaW5nLCBpcyBlc2Nh cGVkIGJ5IHF1b3Rlcy4gKi8KLQkJaWYgKCFpbnNpbmdsZSAmJiAhaW5kb3VibGUgJiYgKGNoID0g Z2V0Y2hhcigpKSA9PSBFT0YpCi0JCQllcnJ4KDEsICJiYWNrc2xhc2ggYXQgRU9GIik7CisJCWlm ICghaW5zaW5nbGUgJiYgIWluZG91YmxlICYmIChjaCA9IGdldGNoYXIoKSkgPT0gRU9GKSB7CisJ CQl3YXJueCgiYmFja3NsYXNoIGF0IEVPRiIpOworCQkJeGV4aXQoKmF2LCAxKTsKKwkJfQogCQkv KiBGQUxMVEhST1VHSCAqLwogCWRlZmF1bHQ6CiBhZGRjaDoJCWlmIChwIDwgZWJwKSB7CkBAIC00 MDQsMTEgKzQwOSwxNSBAQAogCQl9CiAKIAkJLyogSWYgb25seSBvbmUgYXJndW1lbnQsIG5vdCBl bm91Z2ggYnVmZmVyIHNwYWNlLiAqLwotCQlpZiAoYnhwID09IHhwKQotCQkJZXJyeCgxLCAiaW5z dWZmaWNpZW50IHNwYWNlIGZvciBhcmd1bWVudCIpOworCQlpZiAoYnhwID09IHhwKSB7CisJCQl3 YXJueCgiaW5zdWZmaWNpZW50IHNwYWNlIGZvciBhcmd1bWVudCIpOworCQkJeGV4aXQoKmF2LCAx KTsKKwkJfQogCQkvKiBEaWRuJ3QgaGl0IGFyZ3VtZW50IGxpbWl0LCBzbyBpZiB4ZmxhZyBvYmpl Y3QuICovCi0JCWlmICh4ZmxhZykKLQkJCWVycngoMSwgImluc3VmZmljaWVudCBzcGFjZSBmb3Ig YXJndW1lbnRzIik7CisJCWlmICh4ZmxhZykgeworCQkJd2FybngoImluc3VmZmljaWVudCBzcGFj ZSBmb3IgYXJndW1lbnRzIik7CisJCQl4ZXhpdCgqYXYsIDEpOworCQl9CiAKIAkJaWYgKGpmb3Vu ZCkgewogCQkJZm9yIChhdmogPSBhcmd2OyAqYXZqOyBhdmorKykKQEAgLTQ0OSwxNiArNDU4LDIw IEBACiAJICogYSBOVUxMIGF0IHRoZSB0YWlsLgogCSAqLwogCXRtcCA9IG1hbGxvYygoYXJnYyAr IDEpICogc2l6ZW9mKGNoYXIqKikpOwotCWlmICh0bXAgPT0gTlVMTCkKLQkJZXJyeCgxLCAibWFs bG9jIGZhaWxlZCIpOworCWlmICh0bXAgPT0gTlVMTCkgeworCQl3YXJueCgibWFsbG9jIGZhaWxl ZCIpOworCQl4ZXhpdCgqYXJndiwgMSk7CisJfQogCXRtcDIgPSB0bXA7CiAKIAkvKgogCSAqIFNh dmUgdGhlIGZpcnN0IGFyZ3VtZW50IGFuZCBpdGVyYXRlIG92ZXIgaXQsIHdlCiAJICogY2Fubm90 IGRvIHN0cm5zdWJzdCgpIHRvIGl0LgogCSAqLwotCWlmICgoKnRtcCsrID0gc3RyZHVwKCphdmor KykpID09IE5VTEwpCi0JCWVycngoMSwgInN0cmR1cCBmYWlsZWQiKTsKKwlpZiAoKCp0bXArKyA9 IHN0cmR1cCgqYXZqKyspKSA9PSBOVUxMKSB7CisJCXdhcm54KCJzdHJkdXAgZmFpbGVkIik7CisJ CXhleGl0KCphcmd2LCAxKTsKKwl9CiAKIAkvKgogCSAqIEZvciBlYWNoIGFyZ3VtZW50IHRvIHV0 aWxpdHksIGlmIHdlIGhhdmUgbm90IHVzZWQgdXAKQEAgLTQ3NSw4ICs0ODgsMTAgQEAKIAkJCWlm IChyZXBscyA+IDApCiAJCQkJcmVwbHMtLTsKIAkJfSBlbHNlIHsKLQkJCWlmICgoKnRtcCA9IHN0 cmR1cCgqdG1wKSkgPT0gTlVMTCkKLQkJCQllcnJ4KDEsICJzdHJkdXAgZmFpbGVkIik7CisJCQlp ZiAoKCp0bXAgPSBzdHJkdXAoKnRtcCkpID09IE5VTEwpIHsKKwkJCQl3YXJueCgic3RyZHVwIGZh aWxlZCIpOworCQkJCXhleGl0KCphcmd2LCAxKTsKKwkJCX0KIAkJCXRtcCsrOwogCQl9CiAJfQpA QCAtNTQ3LDcgKzU2Miw4IEBACiAJY2hpbGRlcnIgPSAwOwogCXN3aXRjaCAocGlkID0gdmZvcmso KSkgewogCWNhc2UgLTE6Ci0JCWVycigxLCAidmZvcmsiKTsKKwkJd2FybigidmZvcmsiKTsKKwkJ eGV4aXQoKmFyZ3YsIDEpOwogCWNhc2UgMDoKIAkJaWYgKG9mbGFnKSB7CiAJCQlpZiAoKGZkID0g b3BlbihfUEFUSF9UVFksIE9fUkRPTkxZKSkgPT0gLTEpCkBAIC01OTMsMjYgKzYwOSw0NyBAQAog fQogCiBzdGF0aWMgdm9pZAoreGV4aXQoY29uc3QgY2hhciAqbmFtZSwgY29uc3QgaW50IGV4aXRf Y29kZSkgeworCXdhaXRjaGlsZHJlbihuYW1lLCAxKTsKKwlleGl0KGV4aXRfY29kZSk7Cit9CisK K3N0YXRpYyB2b2lkCiB3YWl0Y2hpbGRyZW4oY29uc3QgY2hhciAqbmFtZSwgaW50IHdhaXRhbGwp CiB7CiAJcGlkX3QgcGlkOwogCWludCBzdGF0dXM7CisJaW50IGNhdXNlX2V4aXQgPSAwOwogCiAJ d2hpbGUgKChwaWQgPSB4d2FpdCh3YWl0YWxsIHx8IHBpZHNfZnVsbCgpLCAmc3RhdHVzKSkgPiAw KSB7Ci0JCS8qIElmIHdlIGNvdWxkbid0IGludm9rZSB0aGUgdXRpbGl0eSwgZXhpdC4gKi8KLQkJ aWYgKGNoaWxkZXJyICE9IDApIHsKKwkJLyogSWYgd2UgY291bGRuJ3QgaW52b2tlIHRoZSB1dGls aXR5LCB3YXJuIGFuZCBmbGFnIGZvciBleGl0LiAqLworCQlpZiAoY2hpbGRlcnIgIT0gMCAmJiBj YXVzZV9leGl0ID09IDApIHsKIAkJCWVycm5vID0gY2hpbGRlcnI7Ci0JCQllcnIoZXJybm8gPT0g RU5PRU5UID8gMTI3IDogMTI2LCAiJXMiLCBuYW1lKTsKKwkJCXdhaXRhbGwgPSAxOworCQkJY2F1 c2VfZXhpdCA9IEVOT0VOVCA/IDEyNyA6IDEyNjsKKwkJCXdhcm4oIiVzIiwgbmFtZSk7CiAJCX0K LQkJaWYgKFdJRlNJR05BTEVEKHN0YXR1cykpCi0JCQllcnJ4KDEsICIlczogdGVybWluYXRlZCB3 aXRoIHNpZ25hbCAlZDsgYWJvcnRpbmciLAorCQkvKgorCQkgKiBJZiB1dGlsaXR5IGV4aXRlZCBi ZWNhdXNlIG9mIGEgc2lnbmFsIG9yIHdpdGggYSB2YWx1ZSBvZgorCQkgKiAyNTUsIHdhcm4gKHBl ciBQT1NJWCksIGFuZCB0aGVuIHdhaXQgdW50aWwgYWxsIG90aGVyCisJCSAqIGNoaWxkcmVuIGhh dmUgZXhpdGVkIGJlZm9yZSBleGl0aW5nIDEtMTI1LiBQT1NJWCByZXF1aXJlcworCQkgKiB4YXJn cyB0byBzdG9wIHJlYWRpbmcgaWYgY2hpbGQgZXhpdHMgYmVjYXVzZSBvZiBhIHNpZ25hbCBvcgor CQkgKiB3aXRoIDI1NSwgYnV0IGl0IGRvZXMgbm90IHJlcXVpcmUgdXMgdG8gZXhpdCBpbW1lZGlh dGVseTsKKwkJICogd2FpdGluZyBpcyBwcmVmZXJhYmxlIHRvIG9ycGhhbmluZy4KKwkJICovCisJ CWlmIChXSUZTSUdOQUxFRChzdGF0dXMpKSB7CisJCQl3YWl0YWxsID0gY2F1c2VfZXhpdCA9IDE7 CisJCQl3YXJueCgiJXM6IHRlcm1pbmF0ZWQgd2l0aCBzaWduYWwgJWQ7IGFib3J0aW5nIiwKIAkJ CSAgICBuYW1lLCBXVEVSTVNJRyhzdGF0dXMpKTsKLQkJaWYgKFdFWElUU1RBVFVTKHN0YXR1cykg PT0gMjU1KQotCQkJZXJyeCgxLCAiJXM6IGV4aXRlZCB3aXRoIHN0YXR1cyAyNTU7IGFib3J0aW5n IiwgbmFtZSk7Ci0JCWlmIChXRVhJVFNUQVRVUyhzdGF0dXMpKQotCQkJcnZhbCA9IDE7CisJCX0g ZWxzZSBpZiAoV0VYSVRTVEFUVVMoc3RhdHVzKSA9PSAyNTUpIHsKKwkJCXdhaXRhbGwgPSBjYXVz ZV9leGl0ID0gMTsKKwkJCXdhcm54KCIlczogZXhpdGVkIHdpdGggc3RhdHVzIDI1NTsgYWJvcnRp bmciLCBuYW1lKTsKKwkJfSBlbHNlIGlmIChXRVhJVFNUQVRVUyhzdGF0dXMpKQorIAkJCXJ2YWwg PSAxOwogCX0KIAorIAlpZiAoY2F1c2VfZXhpdCkKKwkJZXhpdChjYXVzZV9leGl0KTsKIAlpZiAo cGlkID09IC0xICYmIGVycm5vICE9IEVDSElMRCkKIAkJZXJyKDEsICJ3YWl0cGlkIik7CiB9Cg== --20cf3071cde288766004bae7991f-- From owner-freebsd-arch@FreeBSD.ORG Sat Mar 10 22:34:54 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6A8CD106566C for ; Sat, 10 Mar 2012 22:34:54 +0000 (UTC) (envelope-from freebsd-arch@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id 259058FC08 for ; Sat, 10 Mar 2012 22:34:53 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1S6Uda-0000R8-CG for freebsd-arch@freebsd.org; Sat, 10 Mar 2012 23:19:42 +0100 Received: from cpe-188-129-114-216.dynamic.amis.hr ([188.129.114.216]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 10 Mar 2012 23:19:42 +0100 Received: from ivoras by cpe-188-129-114-216.dynamic.amis.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 10 Mar 2012 23:19:42 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-arch@freebsd.org From: Ivan Voras Date: Sat, 10 Mar 2012 23:19:06 +0100 Lines: 13 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: cpe-188-129-114-216.dynamic.amis.hr User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 Subject: Offtopic: Linus on binary compatibility X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2012 22:34:54 -0000 https://lkml.org/lkml/2012/3/8/495 Awww, how cute, the little OS is growing up :) Seriously, FreeBSD's ability to run binaries compiled on 3.x on 9.x is incredibly awesome! Now it's only a matter of time when Linus gets it that the kernel ABI should also fall under such rules, and in just a few short years we will have another usable / non-broken OS ;) [end tongue-in-cheek transmission]