From owner-freebsd-arch@FreeBSD.ORG Sun Mar 11 02:55:08 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 BADBF106566C; Sun, 11 Mar 2012 02:55:08 +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 7F3AA8FC08; Sun, 11 Mar 2012 02:55:08 +0000 (UTC) Received: by dald2 with SMTP id d2so3730011dal.13 for ; Sat, 10 Mar 2012 18:55:08 -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; bh=3PFtmls7CJ/GpJGdULIBzVpsJCiaats9u/7WrtZxH7I=; b=aNoxQGqqAMnl6tAYQb3afeRvFoUA0OahQjMrpsHAc4m6a+k8510FnfMnPWyQYRJsrB VdUNg43lEsd5eF+hNW7nv3LktYkC6GI4f0aj2BFpYuEBDqcL/3O5uENFPbbbXYmM3JFH teyniTjBpde+fah7KTOGfWEu2BQbUlwgfW5/TgLvD4Nh1uekAwu/pU5hijRCaoUhL/XO 3kUof8Ig6GanPP3is2czfFvhWuzDzWqT5W59L9g+lXJbRrDMcDyrmDsrwfTf3+eKI6TS 2moule5BSS+onZcJHZiQbPBzsEBQaT49+PKUYGqQhEnGeB6VF7gUTy1Q+L3BW8zN9G6t t16A== MIME-Version: 1.0 Received: by 10.68.225.104 with SMTP id rj8mr12312548pbc.135.1331434507902; Sat, 10 Mar 2012 18:55:07 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.143.33.5 with HTTP; Sat, 10 Mar 2012 18:55:07 -0800 (PST) In-Reply-To: References: Date: Sat, 10 Mar 2012 18:55:07 -0800 X-Google-Sender-Auth: 5AwhswiYNLTpF5GV0A6rUedDV34 Message-ID: From: Adrian Chadd To: Ivan Voras Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-arch@freebsd.org Subject: Re: 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: Sun, 11 Mar 2012 02:55:08 -0000 On 10 March 2012 14:19, Ivan Voras wrote: > 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! .. and someone should write an lkml article on the challenges in doing exactly that. Adrian > 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] > > > _______________________________________________ > 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 Sun Mar 11 17:55:21 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 9E8AA1065672; Sun, 11 Mar 2012 17:55:21 +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 544FA8FC1A; Sun, 11 Mar 2012 17:55:21 +0000 (UTC) Received: by iahk25 with SMTP id k25so7236599iah.13 for ; Sun, 11 Mar 2012 10:55: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 :content-transfer-encoding; bh=j4FH68a6nSz3SRjJ+ATXD/PzEvCSjivmFoybUt1aLK0=; b=qSbpBFq0xuCtU+YW8+fXW1IJcZ+Bt+A++JtRzE0W8pva7E/3cE3dd7A4ozdEPrQyk7 xn0+yhNs1vojYqoNJlvMutrvn3CGyz89ku+Dg2XvxLSg1JwdK+xl9H0X1rjUekjQcRd2 bRNP2jEzVw1YrYNrjcV/b2bXskji406eRGrb71X9nPNbJ3VkO3HxSZ9+WNef2/isGjym 3RyKfGMCs+mGBRf8w34OO5nd7KrtN/XlJUzOi1pf6fmS06WUJfKEvOsBQYguqYktIUDo wvvGZborX+d+PkPYNu3JCl7S+HRiVM6+tGqF4Mn59inm1I6NVBQOfTYEongV2jKI6ak7 IiAA== MIME-Version: 1.0 Received: by 10.50.87.225 with SMTP id bb1mr15275901igb.13.1331488520802; Sun, 11 Mar 2012 10:55:20 -0700 (PDT) Sender: rmh.aybabtu@gmail.com Received: by 10.43.130.201 with HTTP; Sun, 11 Mar 2012 10:55:20 -0700 (PDT) In-Reply-To: References: Date: Sun, 11 Mar 2012 18:55:20 +0100 X-Google-Sender-Auth: UFiMSlid-6ko9L0wH7QXObibqC4 Message-ID: From: Robert Millan To: Adrian Chadd Content-Type: text/plain; charset=UTF-8 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: Sun, 11 Mar 2012 17:55:21 -0000 Hi Adrian, El 9 de mar=C3=A7 de 2012 23:01, Adrian Chadd ha escri= t: > 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. Definitely. This disparity is terribly harmful. I think everybody will agree this is the biggest problem here. I don't think this problem is introduced by my patch though, rather I think my proposal is one of the possible ways to address it. But of course it's not the only way :-) > Why is it that we can't fix the upstream code? Well even with current FreeBSD codebase I see two possible kind of trouble in upstream code: - fails to build - builds successfully but sends I/O to the wrong ports there are many ways upstream code can missbehave and reach either of these problems. As the second one is clearly the worst result, I think that preventing that should be the priority. Bruce made some interesting suggestions.... El 10 de mar=C3=A7 de 2012 14:26, Bruce Evans ha esc= rit: > 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. > > [...] > #error "no user serving parts inside" would prevent cpufunc.h being abuse= d > at any time :-). I think this would give the expected results, as long as we provide a suitable alternative for userland users. >>> FreeBSD code: outw(port, data); >>> Glibc 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. Either way in both cases it looks arbitrary to me. The problem is that they don't match :-( > 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 > % % void > % my_outb(unsigned int port, unsigned char data) > % { > % bus_space_write_1(X86_BUS_SPACE_IO, port, 0, data); > % } > > This gives only minor pessimizations relative to the raw inline asm > outb(). Looks good. So you suggest we tell userspace users to switch to bus_space_write_*? Btw what are the pessimizations? I can't see anything in that function which can't be optimized away after inlining. > 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= . > 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. I could prepare a patch to fix those. > - 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. I wouldn't duplicate outb() in , IIRC its implementation is compiler-dependant so it's not just a one-liner. How about this: - Create - Move outb() et al to that file, and prefix them with two underscores. - Make include and implement outb() as a #define to __outb(). then can include and use __outb() etc. --=20 Robert Millan From owner-freebsd-arch@FreeBSD.ORG Sun Mar 11 19:23:03 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 0070E106564A; Sun, 11 Mar 2012 19:23:03 +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 967058FC14; Sun, 11 Mar 2012 19:23:02 +0000 (UTC) Received: by dald2 with SMTP id d2so4549407dal.13 for ; Sun, 11 Mar 2012 12:23:02 -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=MTCr0oYVpx18rl0ttyhAD7+mw7rm1ihPLjZDoyvrMoo=; b=AC/5KXt19ikX6pozadwD1pCnMVppEmm2Yqx+XkpF6xOYoWk+fQUsz3yNFnQOS7VIgn 8qbhOBlNuvq1BKeAv+uV1wQbJO+F+qfOKh6+vaTW8pmffZK0TRriXtE7HwfihM5yyYlW 19fMI/yWXlAeKK0obW3h4mCQixg9VonNrY5prD++49u4To/ybAMrc0UOUaqR70L6wqTe W1lIrXIUZY3cUOBlX4EZi7SKj2zBED+JNfjgOx2Wor2+11f1/cZkGNgEzqVwzPdYwCdj w2b2QuKfyFsbbEslm7nTN3cXi/8oKq6/UkeNNrbTPCyur5Tdn98GL/Z7uSIdEi/awgND uzzQ== MIME-Version: 1.0 Received: by 10.68.136.231 with SMTP id qd7mr15470459pbb.28.1331493782429; Sun, 11 Mar 2012 12:23:02 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.143.33.5 with HTTP; Sun, 11 Mar 2012 12:23:02 -0700 (PDT) In-Reply-To: References: Date: Sun, 11 Mar 2012 12:23:02 -0700 X-Google-Sender-Auth: 8cfG7gRNdbcxkKi5weAQRquEGHU Message-ID: From: Adrian Chadd To: Robert Millan Content-Type: text/plain; charset=ISO-8859-1 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: Sun, 11 Mar 2012 19:23:03 -0000 Hi, I agree we should move them out of the namespace. I'd even suggest prefixing them with something BSD specific, as two underscores may not be enough of a hint. That requires some sweeping changes of userland code, but I think it's for the best. Bruce? Adrian From owner-freebsd-arch@FreeBSD.ORG Mon Mar 12 01:18:16 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 10EA9106566C; Mon, 12 Mar 2012 01:18:16 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from fallbackmx10.syd.optusnet.com.au (fallbackmx10.syd.optusnet.com.au [211.29.132.251]) by mx1.freebsd.org (Postfix) with ESMTP id 7F4DC8FC0C; Mon, 12 Mar 2012 01:18:15 +0000 (UTC) Received: from mail07.syd.optusnet.com.au (mail07.syd.optusnet.com.au [211.29.132.188]) by fallbackmx10.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q2C1IEUQ013752; Mon, 12 Mar 2012 12:18:14 +1100 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 mail07.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q2C1I3t3018913 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Mar 2012 12:18:04 +1100 Date: Mon, 12 Mar 2012 12:18:02 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Adrian Chadd In-Reply-To: Message-ID: <20120312120436.H1098@besplex.bde.org> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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: Mon, 12 Mar 2012 01:18:16 -0000 On Sun, 11 Mar 2012, Adrian Chadd wrote: > I agree we should move them out of the namespace. I'd even suggest > prefixing them with something BSD specific, as two underscores may not > be enough of a hint. No, they are already outside of the user namespace. cpufunc.h is a kernel header that just happens to be abusable in userland. Though I originally intended it to be usable in userland. 2 underscores would make any use undefined, but no more than most uses already are. > That requires some sweeping changes of userland code, but I think it's > for the best. This would be mostly churn in the downwards direction. I just checked the API in old DOS compilers. In Turbo C it is: #include void outportb(int portid, unsigned char value); [outportb is normally a macro that expands to an inline asm function.] So there is no conflict with this API, since its name is different. Bruce From owner-freebsd-arch@FreeBSD.ORG Mon Mar 12 01:39:11 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 7A75D106566C for ; Mon, 12 Mar 2012 01:39:11 +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 21FFF8FC0C for ; Mon, 12 Mar 2012 01:39:10 +0000 (UTC) Received: by vcmm1 with SMTP id m1so4476241vcm.13 for ; Sun, 11 Mar 2012 18:39:04 -0700 (PDT) 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=XyHMvI2jh8xTcvTZqcX6EQZ6CAwlCQ5zfzRzMXsjpps=; b=Sf032+6mIMbWankp8Ih4Ap9rGbClRwS3Bx9oZJG1ok0kfcrPsqNusSNeoN7YTajrfV 0vl/aymTYdfxr9xVn/sxG5ew4WLZEKeyV59WgdkHZ/E1jHucP77Sh63WMs5eajG2EXZ/ 0VseyJSeP6vyZDH0BbLoB3gLRn307Bl3mdk2KU5KL3lJBbopnBVCp7FF0AI0M3LJcIHj cx75ItT/E3K/7jTyIqk+jjrqRqD3kP35Sr1ZmXYg3dbGhJ+5kUvdeGXxoWbCTvspesw0 iMpGCg/KLPMEo0YLzDE9/VW/3/w4QjfgTgecxGD/IS+onTGsGKXngPoDRo2CbiYbjfGx orng== MIME-Version: 1.0 Received: by 10.52.93.18 with SMTP id cq18mr13310412vdb.40.1331516344453; Sun, 11 Mar 2012 18:39:04 -0700 (PDT) Received: by 10.52.93.42 with HTTP; Sun, 11 Mar 2012 18:39:04 -0700 (PDT) In-Reply-To: References: <20120309225433.GA32725@stack.nl> Date: Sun, 11 Mar 2012 21:39:04 -0400 Message-ID: From: Matthew Story To: freebsd-arch@freebsd.org Content-Type: multipart/mixed; boundary=20cf3071c6aab94b5904bb01ce45 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: Mon, 12 Mar 2012 01:39:11 -0000 --20cf3071c6aab94b5904bb01ce45 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Mar 10, 2012 at 1:23 PM, Matthew Story wrote: > 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 < >>>> matthewstory@gmail.com>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. > Sorry for the noisy updates, but i made the same branching mistake here as in my very first patch, let me know if there are any more issues with this one. (updated the above link, along with attachment). > > >> >> This patch includes the cleaned-up changes Jilles sent back earlier >> (thanks again). >> >> -- >> regards, >> matt >> > > > > -- > regards, > matt > -- regards, matt --20cf3071c6aab94b5904bb01ce45 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_gzoug4sf1 SW5kZXg6IHhhcmdzLjEKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0geGFyZ3MuMQkocmV2aXNpb24gMjMyODQ1KQor KysgeGFyZ3MuMQkod29ya2luZyBjb3B5KQpAQCAtMjk0LDE3ICsyOTQsMTcgQEAKIC5BciB1dGls aXR5CiByZWFkcyBmcm9tIHRoZSBzdGFuZGFyZCBpbnB1dC4KIC5QcAotVGhlCi0uTm0KLXV0aWxp dHkgZXhpdHMgaW1tZWRpYXRlbHkgKHdpdGhvdXQgcHJvY2Vzc2luZyBhbnkgZnVydGhlciBpbnB1 dCkgaWYgYQotY29tbWFuZCBsaW5lIGNhbm5vdCBiZSBhc3NlbWJsZWQsCitJZiBhIGNvbW1hbmQg bGluZSBjYW5ub3QgYmUgYXNzZW1ibGVkLCBvcgorY2Fubm90IGJlIGludm9rZWQsIG9yIGlmIGFu IGludm9jYXRpb24gb2YKIC5BciB1dGlsaXR5Ci1jYW5ub3QgYmUgaW52b2tlZCwgYW4gaW52b2Nh dGlvbiBvZgotLkFyIHV0aWxpdHkKIGlzIHRlcm1pbmF0ZWQgYnkgYSBzaWduYWwsCiBvciBhbiBp bnZvY2F0aW9uIG9mCiAuQXIgdXRpbGl0eQotZXhpdHMgd2l0aCBhIHZhbHVlIG9mIDI1NS4KK2V4 aXRzIHdpdGggYSB2YWx1ZSBvZiAyNTUsIHRoZQorLk5tCit1dGlsaXR5IHN0b3BzIHByb2Nlc3Np bmcgaW5wdXQgYW5kIGV4aXRzIGFmdGVyIGFsbCBpbnZvY2F0aW9ucyBvZgorLkFyIHV0aWxpdHkK K2ZpbmlzaCBwcm9jZXNzaW5nLgogLlNoIEVYSVQgU1RBVFVTCiBUaGUKIC5ObQpJbmRleDogeGFy Z3MuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09Ci0tLSB4YXJncy5jCShyZXZpc2lvbiAyMzI4NDUpCisrKyB4YXJncy5j 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 b3BlbihfUEFUSF9UVFksIE9fUkRPTkxZKSkgPT0gLTEpCkBAIC01OTMsMjYgKzYwOSw0NSBAQAog fQogCiBzdGF0aWMgdm9pZAoreGV4aXQoY29uc3QgY2hhciAqbmFtZSwgY29uc3QgaW50IGV4aXRf Y29kZSkgeworCXdhaXRjaGlsZHJlbihuYW1lLCAxKTsKKwlleGl0KGV4aXRfY29kZSk7Cit9CisK K3N0YXRpYyB2b2lkCiB3YWl0Y2hpbGRyZW4oY29uc3QgY2hhciAqbmFtZSwgaW50IHdhaXRhbGwp CiB7CiAJcGlkX3QgcGlkOwogCWludCBzdGF0dXM7CisJaW50IGNhdXNlX2V4aXQgPSAwOwogCiAJ d2hpbGUgKChwaWQgPSB4d2FpdCh3YWl0YWxsIHx8IHBpZHNfZnVsbCgpLCAmc3RhdHVzKSkgPiAw KSB7Ci0JCS8qIElmIHdlIGNvdWxkbid0IGludm9rZSB0aGUgdXRpbGl0eSwgZXhpdC4gKi8KLQkJ aWYgKGNoaWxkZXJyICE9IDApIHsKKwkJLyoKKwkJICogSWYgd2UgY291bGRuJ3QgaW52b2tlIHRo ZSB1dGlsaXR5IG9yIGlmIHV0aWxpdHkgZXhpdGVkIGJlY2F1c2Ugb2YgYQorCQkgKiBzaWduYWwg b3Igd2l0aCBhIHZhbHVlIG9mIDI1NSwgd2FybiAocGVyIFBPU0lYKSwgYW5kIHRoZW4gd2FpdCB1 bnRpbAorCQkgKiBhbGwgb3RoZXIgY2hpbGRyZW4gaGF2ZSBleGl0ZWQgYmVmb3JlIGV4aXRpbmcg MS0xMjUuIFBPU0lYIHJlcXVpcmVzCisJCSAqIHhhcmdzIHRvIHN0b3AgcmVhZGluZyBpZiBjaGls ZCBleGl0cyBiZWNhdXNlIG9mIGEgc2lnbmFsIG9yICogd2l0aAorCQkgKiAyNTUsIGJ1dCBpdCBk b2VzIG5vdCByZXF1aXJlIHVzIHRvIGV4aXQgaW1tZWRpYXRlbHk7IHdhaXRpbmcgaXMKKwkJICog cHJlZmVyYWJsZSB0byBvcnBoYW5pbmcuCisJCSAqLworCQlpZiAoY2hpbGRlcnIgIT0gMCAmJiBj YXVzZV9leGl0ID09IDApIHsKIAkJCWVycm5vID0gY2hpbGRlcnI7Ci0JCQllcnIoZXJybm8gPT0g RU5PRU5UID8gMTI3IDogMTI2LCAiJXMiLCBuYW1lKTsKLQkJfQotCQlpZiAoV0lGU0lHTkFMRUQo c3RhdHVzKSkKLQkJCWVycngoMSwgIiVzOiB0ZXJtaW5hdGVkIHdpdGggc2lnbmFsICVkOyBhYm9y dGluZyIsCisJCQl3YWl0YWxsID0gMTsKKwkJCWNhdXNlX2V4aXQgPSBFTk9FTlQgPyAxMjcgOiAx MjY7CisJCQl3YXJuKCIlcyIsIG5hbWUpOworCQl9IGVsc2UgaWYgKFdJRlNJR05BTEVEKHN0YXR1 cykpIHsKKwkJCXdhaXRhbGwgPSBjYXVzZV9leGl0ID0gMTsKKwkJCXdhcm54KCIlczogdGVybWlu YXRlZCB3aXRoIHNpZ25hbCAlZDsgYWJvcnRpbmciLAogCQkJICAgIG5hbWUsIFdURVJNU0lHKHN0 YXR1cykpOwotCQlpZiAoV0VYSVRTVEFUVVMoc3RhdHVzKSA9PSAyNTUpCi0JCQllcnJ4KDEsICIl czogZXhpdGVkIHdpdGggc3RhdHVzIDI1NTsgYWJvcnRpbmciLCBuYW1lKTsKLQkJaWYgKFdFWElU U1RBVFVTKHN0YXR1cykpCi0JCQlydmFsID0gMTsKKwkJfSBlbHNlIGlmIChXRVhJVFNUQVRVUyhz dGF0dXMpID09IDI1NSkgeworCQkJd2FpdGFsbCA9IGNhdXNlX2V4aXQgPSAxOworCQkJd2Fybngo IiVzOiBleGl0ZWQgd2l0aCBzdGF0dXMgMjU1OyBhYm9ydGluZyIsIG5hbWUpOworCQl9IGVsc2Ug aWYgKFdFWElUU1RBVFVTKHN0YXR1cykpCisgCQkJcnZhbCA9IDE7CiAJfQogCisgCWlmIChjYXVz ZV9leGl0KQorCQlleGl0KGNhdXNlX2V4aXQpOwogCWlmIChwaWQgPT0gLTEgJiYgZXJybm8gIT0g RUNISUxEKQogCQllcnIoMSwgIndhaXRwaWQiKTsKIH0K --20cf3071c6aab94b5904bb01ce45-- From owner-freebsd-arch@FreeBSD.ORG Mon Mar 12 02:18:53 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 450921065674; Mon, 12 Mar 2012 02:18:53 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from fallbackmx10.syd.optusnet.com.au (fallbackmx10.syd.optusnet.com.au [211.29.132.251]) by mx1.freebsd.org (Postfix) with ESMTP id 8FDE98FC08; Mon, 12 Mar 2012 02:18:52 +0000 (UTC) Received: from mail08.syd.optusnet.com.au (mail08.syd.optusnet.com.au [211.29.132.189]) by fallbackmx10.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q2C2Ip7c017526; Mon, 12 Mar 2012 13:18:51 +1100 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 mail08.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q2C2IfTA008798 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Mar 2012 13:18:42 +1100 Date: Mon, 12 Mar 2012 13:18:41 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Robert Millan In-Reply-To: Message-ID: <20120312121852.P1122@besplex.bde.org> References: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-404940735-1331518721=:1122" Cc: Adrian Chadd , 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: Mon, 12 Mar 2012 02:18:53 -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-404940735-1331518721=:1122 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Sun, 11 Mar 2012, Robert Millan wrote: > Hi Adrian, > > El 9 de mar=C3=A7 de 2012 23:01, Adrian Chadd ha esc= rit: >> 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. > > Definitely. This disparity is terribly harmful. I think everybody > will agree this is the biggest problem here. Why terribly? Code that is chummy enough with the implementation to include an undocumented header to get an undocumented API must know what it is doing. (outb() is not quite undocumented. In all of /usr/share/man, it is mentioned in passing in lpt(4) and ppbus(4), and is fully supported by loader(8), where it is a Forth word. So a non-chummy userland must translate to Forth and exec loader(8) to do outb() for it :-).) > I don't think this problem is introduced by my patch though, rather I > think my proposal is one of the possible ways to address it. But of > course it's not the only way :-) > >> Why is it that we can't fix the upstream code? > > Well even with current FreeBSD codebase I see two possible kind of > trouble in upstream code: > > - fails to build > - builds successfully but sends I/O to the wrong ports > > there are many ways upstream code can missbehave and reach either of > these problems. As the second one is clearly the worst result, I > think that preventing that should be the priority. > > Bruce made some interesting suggestions.... I would prefer to make it fail to build if it gets the arg order wrong, but I don't see how to do that, since both args are integers. >> [...] >> #error "no user serving parts inside" would prevent cpufunc.h being abus= ed >> at any time :-). > > I think this would give the expected results, as long as we provide a > suitable alternative for userland users. Why should we provide it? They should have written their own 1 line of asm. Or they can try using bus space for portability. >>>> FreeBSD code: outw(port, data); >>>> Glibc 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. > > Either way in both cases it looks arbitrary to me. The problem is > that they don't match :-( One conforms to the manufacturer's order and existing practice. >> 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 >> % % void >> % my_outb(unsigned int port, unsigned char data) >> % { >> % bus_space_write_1(X86_BUS_SPACE_IO, port, 0, data); >> % } >> >> This gives only minor pessimizations relative to the raw inline asm >> outb(). > > Looks good. So you suggest we tell userspace users to switch to > bus_space_write_*? The problem with that is that if you don't do the switch yourself then most users won't even know that it is necessary. You have to remove the functionaility in cpufunc.h and/or add messy userland ifdefs as well as messy kernel ifdefs to unremove it, so that users who don't know what they are doing and which you haven't adjusted get warned by build failures. All users that knew what they were doing have to do it differently. > Btw what are the pessimizations? I can't see anything in that > function which can't be optimized away after inlining. There seemed to be an extra load. I'm not sure if the extra level of inlines can do constant folding. But a quick test with inb(0xc2) written as bus_space_read_1(X86_BUS_SPACE_IO, 0xc1, 1) gave good results -- only the source code is ugly. > I could prepare a patch to fix those. > >> - 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. > > I wouldn't duplicate outb() in , IIRC its > implementation is compiler-dependant so it's not just a one-liner. It's a matter of copying a 1-liner from cpufunc.h. outsb() is a few lines, but now it's next to 8 lines of rather bogus inline asm for the MEM case of bus_space_write_multi_1. The IO case takes only 3 lines, and it's strange that the MEM case takes so many more. The inline asm for the MEM case is rather bogus since it is "optimized" to use the lodsb and loop instructions which have been pessimizations for almost 20 years. A simple C loop is probably faster on 486's and later. The x86 bus.h uses these pessimal instructions for most "multi" and "region" MEM i/o's and even for some IO (duh) i/o's. I think simple C loops that build up "multi" and "region" i/o's from "single" (size 1/2/4/8) i/o's would be better on 486's and later in general. This depends on the compiler optimizing away multiple tags comparisons and the like. For most hardware, the tag and loop overhead is irrelevant, since it take a couple of cycles run in parallel with the actual i/o which takes hundreds or thousands of cycles. The x86 bus.h still has many bogus prototypes for static inline functions, with about 15% of the file consisting of duplication for them. In NetBSD, these were to support K&R function definitions, but those never made any sense for inline functions, and FreeBSD never supported K&R for bus space. > How about this: > > - Create > - Move outb() et al to that file, and prefix them with two underscores. Churn. It's already undefined by being documented. However, most of the headers in are bugs. Most of them should have been put in the ${ARCH}/${ARCH} directory (e.g., i386/i386) near the kernel sources that use them. > - Make include and implement > outb() as a #define to __outb(). > > then can include and use __outb() et= c. I don't agree with renaming kernel headers or APIs because applications are chummy with them but not chummy enough to abuse them safely. Bruce --0-404940735-1331518721=:1122-- From owner-freebsd-arch@FreeBSD.ORG Tue Mar 13 17:29:18 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C7E69106564A for ; Tue, 13 Mar 2012 17:29:18 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from mail.ambrisko.com (mail.ambrisko.com [70.91.206.90]) by mx1.freebsd.org (Postfix) with ESMTP id A9E388FC19 for ; Tue, 13 Mar 2012 17:29:18 +0000 (UTC) X-Ambrisko-Me: Yes Received: from server2.ambrisko.com (HELO internal.ambrisko.com) ([192.168.1.2]) by ironport.ambrisko.com with ESMTP; 13 Mar 2012 10:29:23 -0700 Received: from ambrisko.com (localhost [127.0.0.1]) by internal.ambrisko.com (8.14.4/8.14.4) with ESMTP id q2DHTHCI066202 for ; Tue, 13 Mar 2012 10:29:17 -0700 (PDT) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.14.4/8.14.4/Submit) id q2DHTH3b066201 for arch@freebsd.org; Tue, 13 Mar 2012 10:29:17 -0700 (PDT) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <201203131729.q2DHTH3b066201@ambrisko.com> To: arch@freebsd.org Date: Tue, 13 Mar 2012 10:29:17 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL124d (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Cc: Subject: rtld enhancement to add osversion, version 2 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, 13 Mar 2012 17:29:19 -0000 This is round 2 of my rtld enhancements. The primary goal it to have rtld look in different places for libraries depending on the legacy binary that we want to run. This is especially a problem with binaries linked to libraries from ports since the version of a library in /usr/local/lib is the same whether it was FreeBSD 6, 7, 8 etc. until the library itself changes version due to an interface change. At work we need to run 3rd party binaries on our box of which we don't have source. Having a FreeBSD 6 binaries load /usr/local/lib/libiconv.so.3 that was built for FreeBSD 9 is not good. It is worse when libiconv.so.3 is linked to libc.so.7 when the FreeBSD 6 binary needs libc.so.6. I solved this by having rtld extract the OSVERSION from the binary and then use that to determine what to do. In my prior version, I inserted that into the library directory. That meant to pull in libc it would look at: /lib/603000/libc.so.6 /lib/6/libc.so.6 /lib/libc.so.6 to find libc.so.6. This meant a lot more look ups. Also I found it had a problem in that if we had an ambiguous name say /usr/local/lib/libcrypto.so.5 on the FreeBSD 6 machine and /lib/libcrypto.so.5 on the new FreeBSD 8 system, just doing the search logic would get a hit on /lib/libcrypto.so.5 before it got to /usr/local/lib/libcrypto.so.5. So then it would mean we'd have to put all FreeBSD lib's in /lib/6 to beat the search path. This wasn't a good solution. To solve the performance and path issue, I now follow the 32 bit hints file name model. Now it does a lookup of the hints file based on the osversion and major. So now it looks for the hints file as: /var/run/ld-elf-603000.so.hints /var/run/ld-elf-6.so.hints /var/run/ld-elf.so.hints This is faster and has more unique paths for FreeBSD 6 libraries since the FreeBSD 6 search paths would be in the hints file. I modified ldconfig to accept an "-os=" option to create this hints file. I tweaked /etc/rc* to make this easy to setup like this: ldconfig_os_versions="6" ldconfig_6_path="/usr/local/lib/compat/6" This doesn't solve the LD_LIBRARY_PATH or LD_PRELOAD. Solving that I still insert and iterate over the osverion, major and none into the path to find the library. The reason for this is that a FreeBSD 8 binary could exec a FreeBSD 6 binary that execs a FreeBSD 7 binary. If for the FreeBSD 6 binary we needed to set a custom LD_LIBRARY_PATH and the FreeBSD 7 binary find a library via the FreeBSD 6 search path then the FreeBSD 7 binary would die. By adding in the osversion search path I can put the FreeBSD 6 library into the search path + the directory 6. Then only FreeBSD 6 binaries can find it. An example: LD_LIBRARY_PATH=/usr/custom_software/lib /usr/custom_software/lib/6/libfoo.so.6 then only the FreeBSD 6 binary could load it. Since the searches would be for the FreeBSD 6 binary: /usr/custom_software/lib/603000/libfoo.so.6 /usr/custom_software/lib/6/libfoo.so.6 /usr/custom_software/lib/libfoo.so.6 and for FreeBSD 7 binary: /usr/custom_software/lib/702000/libfoo.so.6 /usr/custom_software/lib/7/libfoo.so.6 /usr/custom_software/lib/libfoo.so.6 Only the FreeBSD 6 binary would load /usr/custom_software/lib/6/libfoo.so.6. I do the same search with LD_PRELOAD. Final, is that prior binaries built on FreeBSD i386 but run on FreeBSD amd64 that set LD_* environemnt variables would fail on FreeBSD amd64 as is since it didn't set the equivalent LD32_*. To address this for COMPAT_32BIT I have rtld look for LD32_* first and then check for the LD_* second. This way legacy applications work fine. The patch is at: http://people.freebsd.org/~ambrisko/rtld_hints_osversion.patch and has been tested a fair amount at work. It can make running a different version of a FreeBSD binary very easy without having any cross-linking. There is a bug in FreeBSD 6.0 that didn't record the osversion in the binary so then this doesn't work. Try to avoid those binaries! We have a local hack that says if there is no osversion then assume it is a 6 binary. Again, this is to solve running legacy binaries on a new version of FreeBSD of which we don't have source to recompile with new ld features of -z origin. Comments? Thanks, Doug A. From owner-freebsd-arch@FreeBSD.ORG Wed Mar 14 23:43:49 2012 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A1B1E1065674 for ; Wed, 14 Mar 2012 23:43:49 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from mx0.hoeg.nl (mx0.hoeg.nl [IPv6:2a01:4f8:101:5343::aa]) by mx1.freebsd.org (Postfix) with ESMTP id 43D848FC18 for ; Wed, 14 Mar 2012 23:43:48 +0000 (UTC) Received: by mx0.hoeg.nl (Postfix, from userid 1000) id 2F6DB2A28CCA; Thu, 15 Mar 2012 00:43:48 +0100 (CET) Date: Thu, 15 Mar 2012 00:43:48 +0100 From: Ed Schouten To: arch@FreeBSD.org Message-ID: <20120314234348.GL27469@hoeg.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2EnvhqpWJq810sZn" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Subject: kill(2) man page: ESRCH 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: Wed, 14 Mar 2012 23:43:49 -0000 --2EnvhqpWJq810sZn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi all, Just a quick question. The kill(2) man page says: The kill() system call will fail and no signal will be sent if: [ESRCH] The process id was given as 0 but the sending proce= ss does not have a process group. My question is: is this possible? I thought all processes have a process group. POSIX also doesn't mention anything about this case specifically. Shall I zap this? --=20 Ed Schouten WWW: http://80386.nl/ --2EnvhqpWJq810sZn Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iQIcBAEBAgAGBQJPYS00AAoJEG5e2P40kaK7mHQP+wTOE12qlnZr0x1V8Goy6InX bJjTICO9MWe/vFlihQGC0ZYWkHyg2Z1bs5MRGQVvKwa3b7enu/HZIXJn9M62gRPN dCaMIyc9oFXA8k7fE15TGde8E6YEHU70ASAOiyEr/Idr9fPEFT3bwJ9wk5LsqYe1 Wu0yq1rCj9gWYvlH635YoxaDByS4o46gjV4ECouAJr/PWDDry8yunCKtlD8cbOeX boSTTZkIU+c3TjcS9/SxIVEV4aEgUWseEyLihxJumUis9yr3DdYUrILWN/Qz4lWT vO2dWaAXo6qTyjzGEtL+fbh/edRHiepkjM12Cv9FqYie7+QjpbypUctPe5NHRpvN D7lHuB/+U1y68RhFbFTGfxs+IYkZgNcdnl2N2PKMGgIKaeKC9EUq2Ma+8J6WNWvW hWwZP2tcYa+PJXqZJ9YFHexq13n53JBfwyEO3tv5rYdKpclmEJuySSXmwVSjv0u5 0tbGC1i0lj7u+JbSIRZLaG1P/t1nlJYcqEK7MNuBsMmD4b7oxLevFCkhnVXtQlFm /YIa3tXq5XHbTLvG6B/Gwrwr9La4ZsqkBkogOL9NOWMenFIwkaXPKBj9O1Qj9V8m lzJnesWafFYVIiLd5MWKn5D5imbExRH+d+p+14wqdx3GEsKuHxK8Q0m3RbgatPaV Q4tBMEG401YH98hL0LBd =rpA5 -----END PGP SIGNATURE----- --2EnvhqpWJq810sZn-- From owner-freebsd-arch@FreeBSD.ORG Thu Mar 15 09:34:33 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9AF56106566C for ; Thu, 15 Mar 2012 09:34:33 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id E85978FC15 for ; Thu, 15 Mar 2012 09:34:32 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q2F9XOEO002782; Thu, 15 Mar 2012 11:33:24 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q2F9XNVN072812; Thu, 15 Mar 2012 11:33:23 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q2F9XNcM072811; Thu, 15 Mar 2012 11:33:23 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 15 Mar 2012 11:33:23 +0200 From: Konstantin Belousov To: Ed Schouten Message-ID: <20120315093323.GL75778@deviant.kiev.zoral.com.ua> References: <20120314234348.GL27469@hoeg.nl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Xu/gmhi9npES5AGc" Content-Disposition: inline In-Reply-To: <20120314234348.GL27469@hoeg.nl> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: arch@freebsd.org Subject: Re: kill(2) man page: ESRCH 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: Thu, 15 Mar 2012 09:34:33 -0000 --Xu/gmhi9npES5AGc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Mar 15, 2012 at 12:43:48AM +0100, Ed Schouten wrote: > Hi all, >=20 > Just a quick question. The kill(2) man page says: >=20 > The kill() system call will fail and no signal will be sent if: >=20 > [ESRCH] The process id was given as 0 but the sending pro= cess > does not have a process group. >=20 > My question is: is this possible? I thought all processes have a process > group. POSIX also doesn't mention anything about this case specifically. > Shall I zap this? I think this is a bad wording in the man page, up to the point of error. If the kill pid argument is negative, and corresponding process group cannot be found, then ERSCH is returned, look at the killpg1(9) implementation. The case of pgrp =3D=3D 0 indeed cannot result in ESRCH. The later loop over pg_members shall find at least the sender itself, if pgrp =3D=3D 0. --Xu/gmhi9npES5AGc Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk9ht2MACgkQC3+MBN1Mb4iGuwCfQTq2tRKHcpBVhQwcJNKxbimV B2sAoM0aU2Ux6Yi1mBw1P/dM9Wg/fAU3 =jiX0 -----END PGP SIGNATURE----- --Xu/gmhi9npES5AGc-- From owner-freebsd-arch@FreeBSD.ORG Thu Mar 15 11:47:35 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 47A0C106566B for ; Thu, 15 Mar 2012 11:47:35 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from mx0.hoeg.nl (mx0.hoeg.nl [178.63.0.170]) by mx1.freebsd.org (Postfix) with ESMTP id 0545C8FC15 for ; Thu, 15 Mar 2012 11:47:34 +0000 (UTC) Received: by mx0.hoeg.nl (Postfix, from userid 1000) id EEF2C2A28CD0; Thu, 15 Mar 2012 12:47:27 +0100 (CET) Date: Thu, 15 Mar 2012 12:47:27 +0100 From: Ed Schouten To: Konstantin Belousov Message-ID: <20120315114727.GM27469@hoeg.nl> References: <20120314234348.GL27469@hoeg.nl> <20120315093323.GL75778@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FxlYARId5dseejUu" Content-Disposition: inline In-Reply-To: <20120315093323.GL75778@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: arch@freebsd.org Subject: Re: kill(2) man page: ESRCH 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: Thu, 15 Mar 2012 11:47:35 -0000 --FxlYARId5dseejUu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Kostik, * Konstantin Belousov , 20120315 10:33: > The case of pgrp =3D=3D 0 indeed cannot result in ESRCH. The later loop o= ver > pg_members shall find at least the sender itself, if pgrp =3D=3D 0. Exactly! I'll remove it from the man page. --=20 Ed Schouten WWW: http://80386.nl/ --FxlYARId5dseejUu Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iQIcBAEBAgAGBQJPYdbPAAoJEG5e2P40kaK7jewQAKm5F17Fiaue2yvkrh48357A AH1HDtvfSFMsKQXjTAcLNwXauGyNTb5b4g7nyn1UXxA1wQB6HZVfxHHb0Zwo3v66 c65rs0ARE6/BFRxfTG4CkVzwQUIYl2LeLxCPQnO+SdixaZjPEAv/ayWIcopak1aZ Ok9zApmypEe0OV8h/8wkYG6MNxCSTeqO8wARcMyc1zf25t0JBDLDYwB9P8GgEqwM HEzEKpnisxuAyMbsk+Fg/783FfMLEDGa2UEBUEVxrkJOITzNeCnXpoy12Sh4uBwk g0ME8I4h6V1Hkj4RHO7Fx2r8myIfTcJ3pmbyPy66Q/G1oNzCbMX84qMqZmzg6sRY w17bYduJEPe9nw+C4Aiz4gVzL8HrkuIa4wMTtncBbQ1ay+ROgElQDeDDShzI9Gkh i+/SgEGmZ+SGX4LCKqbpzdkNnA1nRDb1lM3ecSMdKqc4FN6h+3w5nedGUMJcfeQD uaDa4hOQFiLcCRBGpuuoFdGgrWQcOH2HRMuY1aLMyqljB8Zu7wGrzh/9b39Q2aU1 AJ2zGCUGMd+0amyG4VNVDnzhbA9Jjgzrm4MQt3NV6kRSl6OgNTTlONIQI8mefLHW 3rtDBcSWJerhP16FjCd6Pg0ieN3BjIYCLXKaBew5nvyTNFmqG2W02JkolVhkhlFF Z5rW+PnABUpvIRB1Gi22 =ULl5 -----END PGP SIGNATURE----- --FxlYARId5dseejUu-- From owner-freebsd-arch@FreeBSD.ORG Thu Mar 15 11:57:06 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A5C59106566B for ; Thu, 15 Mar 2012 11:57:06 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id CE8918FC0A for ; Thu, 15 Mar 2012 11:57:05 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q2FBuvoR016405; Thu, 15 Mar 2012 13:56:57 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q2FBuvC6005338; Thu, 15 Mar 2012 13:56:57 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q2FBuvox005337; Thu, 15 Mar 2012 13:56:57 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 15 Mar 2012 13:56:57 +0200 From: Konstantin Belousov To: Ed Schouten Message-ID: <20120315115657.GQ75778@deviant.kiev.zoral.com.ua> References: <20120314234348.GL27469@hoeg.nl> <20120315093323.GL75778@deviant.kiev.zoral.com.ua> <20120315114727.GM27469@hoeg.nl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6sjcqG678OIER3jL" Content-Disposition: inline In-Reply-To: <20120315114727.GM27469@hoeg.nl> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: arch@freebsd.org Subject: Re: kill(2) man page: ESRCH 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: Thu, 15 Mar 2012 11:57:06 -0000 --6sjcqG678OIER3jL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Mar 15, 2012 at 12:47:27PM +0100, Ed Schouten wrote: > Hi Kostik, >=20 > * Konstantin Belousov , 20120315 10:33: > > The case of pgrp =3D=3D 0 indeed cannot result in ESRCH. The later loop= over > > pg_members shall find at least the sender itself, if pgrp =3D=3D 0. >=20 > Exactly! I'll remove it from the man page. No, this is wrong. ESRCH is the valid error return, just the description is bogus, and should be updated. --6sjcqG678OIER3jL Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk9h2QkACgkQC3+MBN1Mb4hjvgCgtHKqJxpWZ2Jl3TjzTkBYEJ8U SS8AmwZaFOsOnw1hsaBKs3acuKnUnawc =EwA0 -----END PGP SIGNATURE----- --6sjcqG678OIER3jL-- From owner-freebsd-arch@FreeBSD.ORG Thu Mar 15 12:07:21 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 86EC41065673 for ; Thu, 15 Mar 2012 12:07:21 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from mx0.hoeg.nl (mx0.hoeg.nl [IPv6:2a01:4f8:101:5343::aa]) by mx1.freebsd.org (Postfix) with ESMTP id 2045B8FC0A for ; Thu, 15 Mar 2012 12:07:21 +0000 (UTC) Received: by mx0.hoeg.nl (Postfix, from userid 1000) id 5AADB2A28CD0; Thu, 15 Mar 2012 13:07:20 +0100 (CET) Date: Thu, 15 Mar 2012 13:07:20 +0100 From: Ed Schouten To: Konstantin Belousov Message-ID: <20120315120720.GN27469@hoeg.nl> References: <20120314234348.GL27469@hoeg.nl> <20120315093323.GL75778@deviant.kiev.zoral.com.ua> <20120315114727.GM27469@hoeg.nl> <20120315115657.GQ75778@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dPW7zu3hTOhZvCDO" Content-Disposition: inline In-Reply-To: <20120315115657.GQ75778@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: arch@freebsd.org Subject: Re: kill(2) man page: ESRCH 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: Thu, 15 Mar 2012 12:07:21 -0000 --dPW7zu3hTOhZvCDO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Kostik, * Konstantin Belousov , 20120315 12:56: > No, this is wrong. ESRCH is the valid error return, just the description > is bogus, and should be updated. But wait. There are two ESRCH entries in the man page. I only removed the one that is invalid. If we want to improve the wording of the man page (which is unrelated to my change), we should commit something like: Index: kill.2 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- kill.2 (Revision 233002) +++ kill.2 (Arbeitskopie) @@ -121,7 +121,7 @@ argument is not a valid signal number. .It Bq Er ESRCH -No process can be found corresponding to that specified by +No process or process group can be found corresponding to that specified by .Fa pid . .It Bq Er EPERM The sending process is not the super-user and its effective --=20 Ed Schouten WWW: http://80386.nl/ --dPW7zu3hTOhZvCDO Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iQIcBAEBAgAGBQJPYdt4AAoJEG5e2P40kaK7cwYQAICnqG2CljdbaoGP0HV/IXbR 0IWyYZsMrbfu66j9ndSuBigCA2bPXpRU1kvx/03jcjxpj54zZWPjwFUYnLZiy9Am 5EwSFCQblE4vWC/Ceb1koV6+FUPxt6QHviH7rJJq21UhlwZUSbM3oElrSog8ho3a WXi63NFTVQTnIgwFPRoocwOZtZ28k0otWKKyBp2RjktMVHueB/lj8+WGDR16b85u ZXb5/oisNVLzH2Y6sYIopeJoQc39np2QinNc+YftG4cER4b4qHVG1F4f6DrMyF93 Y58AiSFZEoglAT8k5r3Mk4CbAANQlfLkcTDhypcV9hayMl1wBO0UK+dtv1l1GT34 1NZ5jm9U4YPMz7R44hwNUMoGFcELXoKpYqROMR1sZsDM1FxmlXOK4vCfnCNXuBef OG70Fkut1rahIyR67uNgOtagMRAsQpUD3HpjlUZjz78htR5o4ABRfrPj5GtW/Owe NtyshJIjSynnSJwbfYWNmVn/ETH4llpdQOw1FEADky3+c8wI6SFLB/7Sx4Vro5Ty J/7+BTzHiQm/m3UOzqRHVW2ulApYj6j5MpqS9bJgkCnFIo8cP84B5xX60M61px7D 21bTh6zNzpuqfH6MWNix8fFmNSjx1r0pNYk5h2KOjWyU1dXkE8cOui55pScAWyyD NqBO4eHCNNg89AZ1q402 =wKEY -----END PGP SIGNATURE----- --dPW7zu3hTOhZvCDO-- From owner-freebsd-arch@FreeBSD.ORG Thu Mar 15 12:10:42 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 D2CEB106564A for ; Thu, 15 Mar 2012 12:10:42 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 466F98FC16 for ; Thu, 15 Mar 2012 12:10:41 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q2FCAYcr017595; Thu, 15 Mar 2012 14:10:34 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q2FCAYcI015597; Thu, 15 Mar 2012 14:10:34 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q2FCAYEm015596; Thu, 15 Mar 2012 14:10:34 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 15 Mar 2012 14:10:34 +0200 From: Konstantin Belousov To: Ed Schouten Message-ID: <20120315121034.GS75778@deviant.kiev.zoral.com.ua> References: <20120314234348.GL27469@hoeg.nl> <20120315093323.GL75778@deviant.kiev.zoral.com.ua> <20120315114727.GM27469@hoeg.nl> <20120315115657.GQ75778@deviant.kiev.zoral.com.ua> <20120315120720.GN27469@hoeg.nl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="BvbikYKho79mcz9a" Content-Disposition: inline In-Reply-To: <20120315120720.GN27469@hoeg.nl> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: arch@freebsd.org Subject: Re: kill(2) man page: ESRCH 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: Thu, 15 Mar 2012 12:10:42 -0000 --BvbikYKho79mcz9a Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Mar 15, 2012 at 01:07:20PM +0100, Ed Schouten wrote: > Kostik, >=20 > * Konstantin Belousov , 20120315 12:56: > > No, this is wrong. ESRCH is the valid error return, just the description > > is bogus, and should be updated. >=20 > But wait. There are two ESRCH entries in the man page. I only removed > the one that is invalid. >=20 > If we want to improve the wording of the man page (which is unrelated to > my change), we should commit something like: >=20 > Index: kill.2 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- kill.2 (Revision 233002) > +++ kill.2 (Arbeitskopie) > @@ -121,7 +121,7 @@ > argument > is not a valid signal number. > .It Bq Er ESRCH > -No process can be found corresponding to that specified by > +No process or process group can be found corresponding to that specified= by > .Fa pid . > .It Bq Er EPERM > The sending process is not the super-user and its effective And this is fine. --BvbikYKho79mcz9a Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk9h3DoACgkQC3+MBN1Mb4iqwgCg1vCVYugcNLwxMNwCjXPfqt+Z 3q8AoOzevgTRvKdu7XFXs0inFGBzgfQR =qMTe -----END PGP SIGNATURE----- --BvbikYKho79mcz9a-- From owner-freebsd-arch@FreeBSD.ORG Thu Mar 15 12:16:16 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 9657A106566B for ; Thu, 15 Mar 2012 12:16:16 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 176D88FC24 for ; Thu, 15 Mar 2012 12:16:15 +0000 (UTC) Received: by lboi15 with SMTP id i15so1864078lbo.13 for ; Thu, 15 Mar 2012 05:16:14 -0700 (PDT) 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:content-transfer-encoding; bh=vuFcLXxVeys3aIsO3PMmJ3Lzj99I54CSamwZ8ONazU0=; b=rjZ7t0AjAGkkUZHd2Cuonw2NU0fz2tBi6GYyMC7iBUFkeeD9BgK45naVBoCxoEuZd/ HM3A9l95LW4eeCJ3bhwmhsh+u5e63gOXlRr3BnASZFPBJenQu7CRMIgfEFvO3qJr+axB qDqWw5KKPxMa4kbzNVZs+eQCgCRmJHmZbFBKGXkNahmxvVpFQwYXDDQ4GapX717JSuzb VEd0eeULk//ih9TiJsv+1+ctpbvpmvGs2BxiSfHqM/yn63ZqIuvYTOppyyP0W/37cP2I qFsK/uw71qq1+d5xSEBe8lfcpAkmqKF2TqnViDecTngSwNAoa++aCHU6LC/C491qN8gv hbHA== MIME-Version: 1.0 Received: by 10.112.102.161 with SMTP id fp1mr2211482lbb.71.1331813774412; Thu, 15 Mar 2012 05:16:14 -0700 (PDT) Received: by 10.152.21.73 with HTTP; Thu, 15 Mar 2012 05:16:14 -0700 (PDT) In-Reply-To: <20120314234348.GL27469@hoeg.nl> References: <20120314234348.GL27469@hoeg.nl> Date: Thu, 15 Mar 2012 15:16:14 +0300 Message-ID: From: Sergey Kandaurov To: Ed Schouten Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: arch@freebsd.org Subject: Re: kill(2) man page: ESRCH 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: Thu, 15 Mar 2012 12:16:16 -0000 On 15 March 2012 03:43, Ed Schouten wrote: > Hi all, > > Just a quick question. The kill(2) man page says: > > =A0 =A0 The kill() system call will fail and no signal will be sent if: > > =A0 =A0 [ESRCH] =A0 =A0 =A0 =A0 =A0 =A0The process id was given as 0 but = the sending process > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0does not have a process gr= oup. > > My question is: is this possible? I thought all processes have a process > group. POSIX also doesn't mention anything about this case specifically. > Shall I zap this? > man killpg(2) should probably be updated as well (and is somewhat referenced from man kill(2): If pid is zero: The sig signal is sent to all processes whose group ID is equa= l to the process group ID of the sender, and for which the proce= ss has permission; this is a variant of killpg(2). ). Currently killpg(2) says: [ESRCH] The process group was given as 0 but the sending process does not have a process group. --=20 wbr, pluknet