From owner-freebsd-emulation@FreeBSD.ORG Mon Jun 6 11:01:39 2005 Return-Path: X-Original-To: emulation@freebsd.org Delivered-To: freebsd-emulation@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BC4F316A41C for ; Mon, 6 Jun 2005 11:01:39 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8054243D4C for ; Mon, 6 Jun 2005 11:01:39 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j56B1c8i065445 for ; Mon, 6 Jun 2005 11:01:38 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j56B1bUs065439 for emulation@freebsd.org; Mon, 6 Jun 2005 11:01:37 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 6 Jun 2005 11:01:37 GMT Message-Id: <200506061101.j56B1bUs065439@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: emulation@FreeBSD.org Cc: Subject: Current problem reports assigned to you X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2005 11:01:39 -0000 Current FreeBSD problem reports Critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2003/06/28] kern/53874 emulation /usr/ports/emulators/linux_base isn't wor 1 problem total. Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2000/09/22] kern/21463 emulation Linux compatability mode should not allow o [2000/11/13] kern/22826 emulation Memory limits have no effect in linux com o [2001/03/28] kern/26171 emulation not work Linux-emulator, but hi is work i p [2002/04/16] kern/37161 emulation ext2 linux file system, error handling la o [2002/11/07] kern/45023 emulation flexlm does not run with linux-base-7, st o [2003/09/24] kern/57192 emulation linux-ibm-java1.4 freeze o [2004/06/20] kern/68131 emulation java/linux-ibm-jdk14: linux ibm jdk 1.4.1 o [2005/01/25] ports/76644 emulation FreeBSD 5.3 will freeze or crash when run o [2005/02/19] i386/77710 emulation Linux page fault sigcontext information i o [2005/05/05] ports/80679 emulation emulators/linux_base-8: Use ${MACHINE_ARC o [2005/05/09] ports/80837 emulation x11-toolkits/linux-gtk: cannot install by o [2005/05/12] ports/80926 emulation running $PREFIX/etc/rc.d/vmware.sh return 12 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [1999/04/16] i386/11165 emulation IBCS2 don't work correctly with PID_MAX 9 o [2000/12/15] kern/23561 emulation Linux compatibility mode does not support o [2001/08/14] kern/29698 emulation linux ipcs doesn'work o [2002/06/12] kern/39201 emulation ptrace(2) and rfork(RFLINUXTHPN) confuse o [2002/08/11] kern/41543 emulation Easier wine/w23 support p [2002/09/04] kern/42404 emulation TIOCSCTTY not implemented in linuxulator s [2002/09/06] kern/42466 emulation linux: 'ipc' typ=258 not implemented p [2003/01/22] kern/47349 emulation Fake a sound ioctl (plus linux hook) o [2003/08/21] kern/55835 emulation Linux IPC emulation missing SETALL syscal o [2004/10/19] ports/72865 emulation emulators/vmware3 crashes on 5.3-STABLE o [2004/10/20] kern/72920 emulation linux emulation : path "prefixing" is not o [2004/10/26] kern/73165 emulation [patch] getting rid of COMPAT_43 dependan o [2004/11/10] kern/73777 emulation [patch] linux emulation: root dir special o [2005/03/19] ports/79009 emulation [patch] Some linux ports are incorrectly o [2005/04/07] ports/79655 emulation linux_base-8 fails to install as non-root 15 problems total. From owner-freebsd-emulation@FreeBSD.ORG Mon Jun 6 13:36:49 2005 Return-Path: X-Original-To: freebsd-emulation@freebsd.org Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9B3F516A41F for ; Mon, 6 Jun 2005 13:36:49 +0000 (GMT) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 845BC43D5D for ; Mon, 6 Jun 2005 13:36:47 +0000 (GMT) (envelope-from avg@icyb.net.ua) Received: from [212.40.38.87] (oddity-e.topspin.kiev.ua [212.40.38.87]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id QAA10883 for ; Mon, 06 Jun 2005 16:36:46 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <42A4516E.8040001@icyb.net.ua> Date: Mon, 06 Jun 2005 16:36:46 +0300 From: Andriy Gapon User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050328) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-emulation@freebsd.org Content-Type: text/plain; charset=KOI8-U Content-Transfer-Encoding: 7bit Subject: [Fwd: Re: kern/81951: [patch] linux emulation: getpriority() returns incorrect value] X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2005 13:36:49 -0000 Dear linux emulation developers, FYI: http://www.freebsd.org/cgi/query-pr.cgi?pr=81951 >Category: kern >Responsible: freebsd-bugs >Synopsis: [patch] linux emulation: getpriority() returns incorrect value >Arrival-Date: Mon Jun 06 13:00:03 GMT 2005 -- Andriy Gapon From owner-freebsd-emulation@FreeBSD.ORG Mon Jun 6 15:57:17 2005 Return-Path: X-Original-To: freebsd-emulation@hub.freebsd.org Delivered-To: freebsd-emulation@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BA35F16A41C; Mon, 6 Jun 2005 15:57:17 +0000 (GMT) (envelope-from arved@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6C95143D1D; Mon, 6 Jun 2005 15:57:17 +0000 (GMT) (envelope-from arved@FreeBSD.org) Received: from freefall.freebsd.org (arved@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j56FvH2r008075; Mon, 6 Jun 2005 15:57:17 GMT (envelope-from arved@freefall.freebsd.org) Received: (from arved@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j56FvHB7008071; Mon, 6 Jun 2005 15:57:17 GMT (envelope-from arved) Date: Mon, 6 Jun 2005 15:57:17 GMT From: Tilman Linneweh Message-Id: <200506061557.j56FvHB7008071@freefall.freebsd.org> To: arved@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-emulation@FreeBSD.org Cc: Subject: Re: kern/81951: [patch] linux emulation: getpriority() returns incorrect value X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2005 15:57:17 -0000 Synopsis: [patch] linux emulation: getpriority() returns incorrect value Responsible-Changed-From-To: freebsd-bugs->freebsd-emulation Responsible-Changed-By: arved Responsible-Changed-When: Mon Jun 6 15:56:58 GMT 2005 Responsible-Changed-Why: Over to emulation mailinglist for review http://www.freebsd.org/cgi/query-pr.cgi?pr=81951 From owner-freebsd-emulation@FreeBSD.ORG Wed Jun 8 19:15:15 2005 Return-Path: X-Original-To: freebsd-emulation@freebsd.org Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F34EA16A41C for ; Wed, 8 Jun 2005 19:15:14 +0000 (GMT) (envelope-from rconan@uvic.ca) Received: from castle.comp.uvic.ca (castle.comp.uvic.ca [142.104.5.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 437FC43D49 for ; Wed, 8 Jun 2005 19:15:13 +0000 (GMT) (envelope-from rconan@uvic.ca) Received: from enezeusa.aolab.me.uvic.ca (cbr-pad.me.UVic.CA [142.104.123.107]) by castle.comp.uvic.ca (8.13.2/8.13.2) with ESMTP id j58JFChx4796520 for ; Wed, 8 Jun 2005 12:15:12 -0700 From: Rodolphe Conan To: freebsd-emulation@freebsd.org Content-Type: text/plain Date: Wed, 08 Jun 2005 12:18:46 -0700 Message-Id: <1118258326.20469.7.camel@enezeusa.aolab.me.uvic.ca> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-UVic-Virus-Scanned: OK - Passed virus scan by Sophos (sophie) on castle X-UVic-Spam-Scan: castle.comp.uvic.ca Not_scanned_LOCAL X-Scanned-By: MIMEDefang 2.33 (www . roaringpenguin . com / mimedefang) Subject: Matlab7 for Linux X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2005 19:15:15 -0000 Hello, I am running FreeBSD 5.3 with linux_base-8 installed. I have installed the linux version of Matlab 7 and now when I start matlab I have this warning message: /compat/linux/usr/local/Matlab/bin/matlab: line 1: /lib/libc.so.6: cannot execute binary file Any idea what does it mean? It doesn't really prevent Matlab to work but I just cannot make 3D surface plots. A simple mesh(zeros(20)) will run forever taken all my cpu!! Thanks for your help Rod From owner-freebsd-emulation@FreeBSD.ORG Wed Jun 8 20:50:19 2005 Return-Path: X-Original-To: freebsd-emulation@hub.freebsd.org Delivered-To: freebsd-emulation@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F38CF16A41C for ; Wed, 8 Jun 2005 20:50:18 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id B15FB43D1D for ; Wed, 8 Jun 2005 20:50:18 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j58KoIwR042127 for ; Wed, 8 Jun 2005 20:50:18 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j58KoIj4042126; Wed, 8 Jun 2005 20:50:18 GMT (envelope-from gnats) Date: Wed, 8 Jun 2005 20:50:18 GMT Message-Id: <200506082050.j58KoIj4042126@freefall.freebsd.org> To: freebsd-emulation@FreeBSD.org From: Maxim Sobolev Cc: Subject: Re: kern/81951: [patch] linux emulation: getpriority() returns incorrect value X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Maxim Sobolev List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2005 20:50:19 -0000 The following reply was made to PR kern/81951; it has been noted by GNATS. From: Maxim Sobolev To: bug-followup@FreeBSD.org, avg@icyb.net.ua Cc: Subject: Re: kern/81951: [patch] linux emulation: getpriority() returns incorrect value Date: Wed, 08 Jun 2005 23:49:33 +0300 Committed, thanks! I wonder if the setpriority(2) needs the same cure. Please clarify and let me know. I'll keep the PR open till your reply. -Maxim From owner-freebsd-emulation@FreeBSD.ORG Thu Jun 9 04:30:18 2005 Return-Path: X-Original-To: freebsd-emulation@hub.freebsd.org Delivered-To: freebsd-emulation@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9A59E16A41C for ; Thu, 9 Jun 2005 04:30:18 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 702A443D1F for ; Thu, 9 Jun 2005 04:30:18 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j594UI2L099078 for ; Thu, 9 Jun 2005 04:30:18 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j594UILr099075; Thu, 9 Jun 2005 04:30:18 GMT (envelope-from gnats) Date: Thu, 9 Jun 2005 04:30:18 GMT Message-Id: <200506090430.j594UILr099075@freefall.freebsd.org> To: freebsd-emulation@FreeBSD.org From: Andriy Gapon Cc: Subject: Re: kern/81951: [patch] linux emulation: getpriority() returns incorrect value X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Andriy Gapon List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2005 04:30:18 -0000 The following reply was made to PR kern/81951; it has been noted by GNATS. From: Andriy Gapon To: Maxim.Sobolev@portaone.com Cc: bug-followup@FreeBSD.org Subject: Re: kern/81951: [patch] linux emulation: getpriority() returns incorrect value Date: Thu, 09 Jun 2005 07:22:32 +0300 on 08.06.2005 23:49 Maxim Sobolev said the following: > Committed, thanks! > > I wonder if the setpriority(2) needs the same cure. Please clarify and > let me know. I'll keep the PR open till your reply. > Maxim, setpriority(2) is not affected, the reason for this assymetry is in Linux's convention for system calls - they return both result and errno in the same register, positive values are reserved for results of successful calls and negative are reserved for -errno for failed calls. Thus they can not return negative priority values in getpriority(2) and have to shift it to positive range. There is no problem, of course, with passing negative values from userland to kernel. Thank you for the commit! -- Andriy Gapon From owner-freebsd-emulation@FreeBSD.ORG Thu Jun 9 13:17:47 2005 Return-Path: X-Original-To: freebsd-emulation@freebsd.org Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8276516A41C; Thu, 9 Jun 2005 13:17:47 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0AB0A43D49; Thu, 9 Jun 2005 13:17:46 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.0.86]) by mailout2.pacific.net.au (8.13.4/8.13.4/Debian-1) with ESMTP id j59DHj2d008307; Thu, 9 Jun 2005 23:17:45 +1000 Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (8.13.4/8.13.4/Debian-1) with ESMTP id j59DHg9H019052; Thu, 9 Jun 2005 23:17:43 +1000 Date: Thu, 9 Jun 2005 23:17:44 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Andriy Gapon In-Reply-To: <200506090430.j594UILr099075@freefall.freebsd.org> Message-ID: <20050609221208.F22195@delplex.bde.org> References: <200506090430.j594UILr099075@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-emulation@freebsd.org, freebsd-gnats-submit@freebsd.org Subject: Re: kern/81951: [patch] linux emulation: getpriority() returns incorrect value X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2005 13:17:47 -0000 > on 08.06.2005 23:49 Maxim Sobolev said the following: > > Committed, thanks! > > > > I wonder if the setpriority(2) needs the same cure. Please clarify and > > let me know. I'll keep the PR open till your reply. I wonder why committers commit patches without fully understanding them. > setpriority(2) is not affected, the reason for this assymetry is in > Linux's convention for system calls - they return both result and errno > in the same register, positive values are reserved for results of > successful calls and negative are reserved for -errno for failed calls. > Thus they can not return negative priority values in getpriority(2) and > have to shift it to positive range. There is no problem, of course, with > passing negative values from userland to kernel. Returning -1 for an error is the usual convention for syscalls and is specified by POSIX for getpriority(). The problem is that FreeBSD's getpriority() is highly non-POSIX-conformant (it has an off-by 20 error and wrong semantics for NZERO, and an off-by 1 error), so it can't be mapped to an emulator's getpriority() using the identity map except in rare cases where the emulator's getpriority() is bug for bug compatible. But Linux's getpriority() seems to be highly non-POSIX-conformant in a different, less fundamentally broken way. POSIX specifies that the non-error range of values returned by getpriority() is [0, 2*{NZERO}-1]; -1 is the error indicator. Applications must subtract NZERO to get the actual priority value. High non-POSIX-conformance: FreeBSD: NZERO is 0, so this range is null, and the actual range is [PRIO_MIN, PRIO_MAX] = [-20, 20]; priority -1 collides with the error indicator (the complications to handle this are documented in getpriority(3)). NZERO is not mentioned in getpriority(3). Linux: NZERO is 20, so the POSIX range is [0, 39] which is usable, but the actual range is apparently [1, 40]; the error indicator works normally. Appalications must apparently negate the priority and add 20 to get the actual priority (20 - pri) instead of (pri - NZERO). I think the reason that setpriority(2) is not affected is actually that Linux applications know to use (20 - pri) to recover the actual priority. Fixing getpriority() in FreeBSD and all emulators should involve much the same code: map the range of internal priorities [PRIO_MIN, PRIO_MAX] to getpriority()'s range [0, 2*{SUBSYSTEM_SPECIFIC_NZERO}-1] as linearly as possible (something like: pri |-> (pri - PRIO_MIN) * (2 * SUBSYSTEM_SPECIFIC_NZERO - 1) / (PRIO_MAX - PRIO_MIN) but more complicated, since for if SUBSYSTEM_SPECIFIC_NZERO == 20 the above maps the default priority 0 to (20 * 39 / 2) = 19, but 20 is required; also for Linux there must be a negation. Bruce From owner-freebsd-emulation@FreeBSD.ORG Thu Jun 9 13:20:07 2005 Return-Path: X-Original-To: freebsd-emulation@hub.freebsd.org Delivered-To: freebsd-emulation@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1F96116A41C for ; Thu, 9 Jun 2005 13:20:07 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id ECE0E43D1F for ; Thu, 9 Jun 2005 13:20:06 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j59DK6Ib095304 for ; Thu, 9 Jun 2005 13:20:06 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j59DK6s5095303; Thu, 9 Jun 2005 13:20:06 GMT (envelope-from gnats) Date: Thu, 9 Jun 2005 13:20:06 GMT Message-Id: <200506091320.j59DK6s5095303@freefall.freebsd.org> To: freebsd-emulation@FreeBSD.org From: Bruce Evans Cc: Subject: Re: kern/81951: [patch] linux emulation: getpriority() returns incorrect value X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Bruce Evans List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2005 13:20:07 -0000 The following reply was made to PR kern/81951; it has been noted by GNATS. From: Bruce Evans To: Andriy Gapon Cc: freebsd-gnats-submit@freebsd.org, freebsd-emulation@freebsd.org Subject: Re: kern/81951: [patch] linux emulation: getpriority() returns incorrect value Date: Thu, 9 Jun 2005 23:17:44 +1000 (EST) > on 08.06.2005 23:49 Maxim Sobolev said the following: > > Committed, thanks! > > > > I wonder if the setpriority(2) needs the same cure. Please clarify and > > let me know. I'll keep the PR open till your reply. I wonder why committers commit patches without fully understanding them. > setpriority(2) is not affected, the reason for this assymetry is in > Linux's convention for system calls - they return both result and errno > in the same register, positive values are reserved for results of > successful calls and negative are reserved for -errno for failed calls. > Thus they can not return negative priority values in getpriority(2) and > have to shift it to positive range. There is no problem, of course, with > passing negative values from userland to kernel. Returning -1 for an error is the usual convention for syscalls and is specified by POSIX for getpriority(). The problem is that FreeBSD's getpriority() is highly non-POSIX-conformant (it has an off-by 20 error and wrong semantics for NZERO, and an off-by 1 error), so it can't be mapped to an emulator's getpriority() using the identity map except in rare cases where the emulator's getpriority() is bug for bug compatible. But Linux's getpriority() seems to be highly non-POSIX-conformant in a different, less fundamentally broken way. POSIX specifies that the non-error range of values returned by getpriority() is [0, 2*{NZERO}-1]; -1 is the error indicator. Applications must subtract NZERO to get the actual priority value. High non-POSIX-conformance: FreeBSD: NZERO is 0, so this range is null, and the actual range is [PRIO_MIN, PRIO_MAX] = [-20, 20]; priority -1 collides with the error indicator (the complications to handle this are documented in getpriority(3)). NZERO is not mentioned in getpriority(3). Linux: NZERO is 20, so the POSIX range is [0, 39] which is usable, but the actual range is apparently [1, 40]; the error indicator works normally. Appalications must apparently negate the priority and add 20 to get the actual priority (20 - pri) instead of (pri - NZERO). I think the reason that setpriority(2) is not affected is actually that Linux applications know to use (20 - pri) to recover the actual priority. Fixing getpriority() in FreeBSD and all emulators should involve much the same code: map the range of internal priorities [PRIO_MIN, PRIO_MAX] to getpriority()'s range [0, 2*{SUBSYSTEM_SPECIFIC_NZERO}-1] as linearly as possible (something like: pri |-> (pri - PRIO_MIN) * (2 * SUBSYSTEM_SPECIFIC_NZERO - 1) / (PRIO_MAX - PRIO_MIN) but more complicated, since for if SUBSYSTEM_SPECIFIC_NZERO == 20 the above maps the default priority 0 to (20 * 39 / 2) = 19, but 20 is required; also for Linux there must be a negation. Bruce From owner-freebsd-emulation@FreeBSD.ORG Thu Jun 9 14:36:28 2005 Return-Path: X-Original-To: freebsd-emulation@freebsd.org Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0330416A41C; Thu, 9 Jun 2005 14:36:28 +0000 (GMT) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id E146543D1F; Thu, 9 Jun 2005 14:36:25 +0000 (GMT) (envelope-from avg@icyb.net.ua) Received: from [212.40.38.87] (oddity-e.topspin.kiev.ua [212.40.38.87]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA22957; Thu, 09 Jun 2005 17:36:06 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <42A853D5.5030003@icyb.net.ua> Date: Thu, 09 Jun 2005 17:36:05 +0300 From: Andriy Gapon User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050328) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bruce Evans References: <200506090430.j594UILr099075@freefall.freebsd.org> <20050609221208.F22195@delplex.bde.org> In-Reply-To: <20050609221208.F22195@delplex.bde.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-emulation@freebsd.org, freebsd-gnats-submit@freebsd.org Subject: Re: kern/81951: [patch] linux emulation: getpriority() returns incorrect value X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2005 14:36:28 -0000 on 09.06.2005 16:17 Bruce Evans said the following: >> on 08.06.2005 23:49 Maxim Sobolev said the following: >> > Committed, thanks! >> > >> > I wonder if the setpriority(2) needs the same cure. Please clarify and >> > let me know. I'll keep the PR open till your reply. > > > I wonder why committers commit patches without fully understanding them. I wonder if you fully understood the patch, the issue and the getriority/setpriority. > >> setpriority(2) is not affected, the reason for this assymetry is in >> Linux's convention for system calls - they return both result and errno >> in the same register, positive values are reserved for results of >> successful calls and negative are reserved for -errno for failed calls. >> Thus they can not return negative priority values in getpriority(2) and >> have to shift it to positive range. There is no problem, of course, with >> passing negative values from userland to kernel. > > > Returning -1 for an error is the usual convention for syscalls and is > specified by POSIX for getpriority(). The problem is that FreeBSD's > getpriority() is highly non-POSIX-conformant (it has an off-by 20 error and > wrong semantics for NZERO, and an off-by 1 error), so it can't be mapped > to an emulator's getpriority() using the identity map except in rare cases > where the emulator's getpriority() is bug for bug compatible. But Linux's > getpriority() seems to be highly non-POSIX-conformant in a different, less > fundamentally broken way. > > POSIX specifies that the non-error range of values returned by > getpriority() > is [0, 2*{NZERO}-1]; -1 is the error indicator. Applications must subtract > NZERO to get the actual priority value. Bruce, I think you have misread POSIX specification and you are confusing two things: (1) priority - priority inside the blackbox that schedules processes versus values that should be passed to setpriotiy() and returned from getpriority(); (2) syscall internal implementation versus user-visible libc function. Regaridng #1, here's a direct quote: http://www.opengroup.org/onlinepubs/009695399/functions/getpriority.html "Upon successful completion, getpriority() shall return an integer in the range -{NZERO} to {NZERO}-1. Otherwise, -1 shall be returned and errno set to indicate the error." Also: "The getpriority() and setpriority() functions work with an offset nice value (nice value -{NZERO}). The nice value is in the range [0,2*{NZERO} -1], while the return value for getpriority() and the third parameter for setpriority() are in the range [-{NZERO},{NZERO} -1]." So this is a difference between priority as it is seen in user-land (above libc layer) and priority inside the POSIX blackbox of OS (the one in [0,2*{NZERO} -1] range). My understanding is that FreeBSD and Linux are very close to POSIXly correct implemetations with NZERO=20. In fact, Linux's implementation is completely compliant and FreeBSD allows +20 which is beyond the POSIX range. Also, -1 return value from getpriority() is a problematic point of POSIX specification not implemenations. Regarding #2, both FreeBSD and Linux in their unique ways correctly return errno/priority level from kernel-land to user-land. FreeBSD syscall returns priority already in [-{NZERO},{NZERO} -1] range; Linux syscall returns priority in [1,2*{NZERO}] range and with reversed comparison, and then (g)libc stub of getpritority performs 20-X conversion to return a correct value to application. > High non-POSIX-conformance: > FreeBSD: > NZERO is 0, so this range is null, and the actual range is [PRIO_MIN, > PRIO_MAX] = [-20, 20]; priority -1 collides with the error indicator > (the complications to handle this are documented in getpriority(3)). > NZERO is not mentioned in getpriority(3). There is no getpriority(3), only getpriority(2) and it quite rightly doesn't talk about NZERO as it is of no interest to applications and it quite rightly talks about troubles with -1 as it is a problem of interface defined by POSIX. > Linux: > NZERO is 20, so the POSIX range is [0, 39] which is usable, but the > actual range is apparently [1, 40]; the error indicator works normally. > Appalications must apparently negate the priority and add 20 to get > the actual priority (20 - pri) instead of (pri - NZERO). > > I think the reason that setpriority(2) is not affected is actually that > Linux applications know to use (20 - pri) to recover the actual priority. > > Fixing getpriority() in FreeBSD and all emulators should involve much the > same code: map the range of internal priorities [PRIO_MIN, PRIO_MAX] to > getpriority()'s range [0, 2*{SUBSYSTEM_SPECIFIC_NZERO}-1] as linearly > as possible (something like: > > pri |-> (pri - PRIO_MIN) * (2 * SUBSYSTEM_SPECIFIC_NZERO - 1) / > (PRIO_MAX - PRIO_MIN) > > but more complicated, since for if SUBSYSTEM_SPECIFIC_NZERO == 20 the > above maps the default priority 0 to (20 * 39 / 2) = 19, but 20 is > required; also for Linux there must be a negation. I think you have greatly overcomplicated thing sbecause of your original misunderstanding. Just compile a small program using getpriority/setpriority for FreeBSD, Linux and any other Unix avaialble to you, run it and you will see how simple thingx are in reality and that NZERO is not visible to userland. Read the man pages too. Yes, and try Linux emulation with and without my patch to understand what the problem with emualtion really is. -- Andriy Gapon From owner-freebsd-emulation@FreeBSD.ORG Thu Jun 9 14:40:15 2005 Return-Path: X-Original-To: freebsd-emulation@hub.freebsd.org Delivered-To: freebsd-emulation@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AB4CE16A41C for ; Thu, 9 Jun 2005 14:40:15 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7D7F943D49 for ; Thu, 9 Jun 2005 14:40:15 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j59EeF2Z004680 for ; Thu, 9 Jun 2005 14:40:15 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j59EeFNa004679; Thu, 9 Jun 2005 14:40:15 GMT (envelope-from gnats) Date: Thu, 9 Jun 2005 14:40:15 GMT Message-Id: <200506091440.j59EeFNa004679@freefall.freebsd.org> To: freebsd-emulation@FreeBSD.org From: Andriy Gapon Cc: Subject: Re: kern/81951: [patch] linux emulation: getpriority() returns incorrect value X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Andriy Gapon List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2005 14:40:15 -0000 The following reply was made to PR kern/81951; it has been noted by GNATS. From: Andriy Gapon To: Bruce Evans Cc: freebsd-gnats-submit@freebsd.org, freebsd-emulation@freebsd.org Subject: Re: kern/81951: [patch] linux emulation: getpriority() returns incorrect value Date: Thu, 09 Jun 2005 17:36:05 +0300 on 09.06.2005 16:17 Bruce Evans said the following: >> on 08.06.2005 23:49 Maxim Sobolev said the following: >> > Committed, thanks! >> > >> > I wonder if the setpriority(2) needs the same cure. Please clarify and >> > let me know. I'll keep the PR open till your reply. > > > I wonder why committers commit patches without fully understanding them. I wonder if you fully understood the patch, the issue and the getriority/setpriority. > >> setpriority(2) is not affected, the reason for this assymetry is in >> Linux's convention for system calls - they return both result and errno >> in the same register, positive values are reserved for results of >> successful calls and negative are reserved for -errno for failed calls. >> Thus they can not return negative priority values in getpriority(2) and >> have to shift it to positive range. There is no problem, of course, with >> passing negative values from userland to kernel. > > > Returning -1 for an error is the usual convention for syscalls and is > specified by POSIX for getpriority(). The problem is that FreeBSD's > getpriority() is highly non-POSIX-conformant (it has an off-by 20 error and > wrong semantics for NZERO, and an off-by 1 error), so it can't be mapped > to an emulator's getpriority() using the identity map except in rare cases > where the emulator's getpriority() is bug for bug compatible. But Linux's > getpriority() seems to be highly non-POSIX-conformant in a different, less > fundamentally broken way. > > POSIX specifies that the non-error range of values returned by > getpriority() > is [0, 2*{NZERO}-1]; -1 is the error indicator. Applications must subtract > NZERO to get the actual priority value. Bruce, I think you have misread POSIX specification and you are confusing two things: (1) priority - priority inside the blackbox that schedules processes versus values that should be passed to setpriotiy() and returned from getpriority(); (2) syscall internal implementation versus user-visible libc function. Regaridng #1, here's a direct quote: http://www.opengroup.org/onlinepubs/009695399/functions/getpriority.html "Upon successful completion, getpriority() shall return an integer in the range -{NZERO} to {NZERO}-1. Otherwise, -1 shall be returned and errno set to indicate the error." Also: "The getpriority() and setpriority() functions work with an offset nice value (nice value -{NZERO}). The nice value is in the range [0,2*{NZERO} -1], while the return value for getpriority() and the third parameter for setpriority() are in the range [-{NZERO},{NZERO} -1]." So this is a difference between priority as it is seen in user-land (above libc layer) and priority inside the POSIX blackbox of OS (the one in [0,2*{NZERO} -1] range). My understanding is that FreeBSD and Linux are very close to POSIXly correct implemetations with NZERO=20. In fact, Linux's implementation is completely compliant and FreeBSD allows +20 which is beyond the POSIX range. Also, -1 return value from getpriority() is a problematic point of POSIX specification not implemenations. Regarding #2, both FreeBSD and Linux in their unique ways correctly return errno/priority level from kernel-land to user-land. FreeBSD syscall returns priority already in [-{NZERO},{NZERO} -1] range; Linux syscall returns priority in [1,2*{NZERO}] range and with reversed comparison, and then (g)libc stub of getpritority performs 20-X conversion to return a correct value to application. > High non-POSIX-conformance: > FreeBSD: > NZERO is 0, so this range is null, and the actual range is [PRIO_MIN, > PRIO_MAX] = [-20, 20]; priority -1 collides with the error indicator > (the complications to handle this are documented in getpriority(3)). > NZERO is not mentioned in getpriority(3). There is no getpriority(3), only getpriority(2) and it quite rightly doesn't talk about NZERO as it is of no interest to applications and it quite rightly talks about troubles with -1 as it is a problem of interface defined by POSIX. > Linux: > NZERO is 20, so the POSIX range is [0, 39] which is usable, but the > actual range is apparently [1, 40]; the error indicator works normally. > Appalications must apparently negate the priority and add 20 to get > the actual priority (20 - pri) instead of (pri - NZERO). > > I think the reason that setpriority(2) is not affected is actually that > Linux applications know to use (20 - pri) to recover the actual priority. > > Fixing getpriority() in FreeBSD and all emulators should involve much the > same code: map the range of internal priorities [PRIO_MIN, PRIO_MAX] to > getpriority()'s range [0, 2*{SUBSYSTEM_SPECIFIC_NZERO}-1] as linearly > as possible (something like: > > pri |-> (pri - PRIO_MIN) * (2 * SUBSYSTEM_SPECIFIC_NZERO - 1) / > (PRIO_MAX - PRIO_MIN) > > but more complicated, since for if SUBSYSTEM_SPECIFIC_NZERO == 20 the > above maps the default priority 0 to (20 * 39 / 2) = 19, but 20 is > required; also for Linux there must be a negation. I think you have greatly overcomplicated thing sbecause of your original misunderstanding. Just compile a small program using getpriority/setpriority for FreeBSD, Linux and any other Unix avaialble to you, run it and you will see how simple thingx are in reality and that NZERO is not visible to userland. Read the man pages too. Yes, and try Linux emulation with and without my patch to understand what the problem with emualtion really is. -- Andriy Gapon From owner-freebsd-emulation@FreeBSD.ORG Fri Jun 10 08:47:49 2005 Return-Path: X-Original-To: emulation@FreeBSD.org Delivered-To: freebsd-emulation@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 065D316A41C for ; Fri, 10 Jun 2005 08:47:49 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.194.102.232]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C82643D4C for ; Fri, 10 Jun 2005 08:47:48 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 1633B511C3; Fri, 10 Jun 2005 04:47:48 -0400 (EDT) Date: Fri, 10 Jun 2005 04:47:47 -0400 From: Kris Kennaway To: Alexander Leidinger Message-ID: <20050610084747.GA44739@xor.obsecurity.org> References: <20050430160341.3a3701fd@Magellan.Leidinger.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cWoXeonUoKmBZSoM" Content-Disposition: inline In-Reply-To: <20050430160341.3a3701fd@Magellan.Leidinger.net> User-Agent: Mutt/1.4.2.1i Cc: emulation@FreeBSD.org Subject: Re: RFC: cleanup of linux ports (enhanced version) X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2005 08:47:49 -0000 --cWoXeonUoKmBZSoM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Apr 30, 2005 at 04:03:41PM +0200, Alexander Leidinger wrote: > Hi, >=20 > at http://www.leidinger.net/FreeBSD/port-patches/ports-WIP.diff is a > mega-patch to cleanup some issues in linux ports. You get this mail > because your port is affected by this patch. This patch is subject to > testing on the ports build cluster (as soon as the necessary resources > are available, not before 5.4-Release), but it would be nice if you > could take a look at parts of the patch which affect your port. [...] FYI, I've been in the process of testing this patch with Alexander. Since it's a large patch, please coordinate or postpone all commits to affected ports to reduce the additional maintenance workload for us. Hopefully we should be done over the weekend. Thanks, Kris --cWoXeonUoKmBZSoM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFCqVOzWry0BWjoQKURAgESAJ9hWRcCKvRqdHdLll5QKHifczBm0gCeLPw3 XDhqbJeHUBvYOyQjOE8MqGs= =6tAK -----END PGP SIGNATURE----- --cWoXeonUoKmBZSoM-- From owner-freebsd-emulation@FreeBSD.ORG Sat Jun 11 18:37:28 2005 Return-Path: X-Original-To: freebsd-emulation@freebsd.org Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E716016A41C; Sat, 11 Jun 2005 18:37:28 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 40E7643D4C; Sat, 11 Jun 2005 18:37:28 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.0.87]) by mailout2.pacific.net.au (8.13.4/8.13.4/Debian-1) with ESMTP id j5BIbQiv013911; Sun, 12 Jun 2005 04:37:26 +1000 Received: from epsplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailproxy2.pacific.net.au (8.13.4/8.13.4/Debian-1) with ESMTP id j5BIbN3w014953; Sun, 12 Jun 2005 04:37:24 +1000 Date: Sun, 12 Jun 2005 04:37:24 +1000 (EST) From: Bruce Evans X-X-Sender: bde@epsplex.bde.org To: Andriy Gapon In-Reply-To: <42A853D5.5030003@icyb.net.ua> Message-ID: <20050612043714.J602@epsplex.bde.org> References: <200506090430.j594UILr099075@freefall.freebsd.org> <20050609221208.F22195@delplex.bde.org> <42A853D5.5030003@icyb.net.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-emulation@freebsd.org, freebsd-gnats-submit@freebsd.org Subject: Re: kern/81951: [patch] linux emulation: getpriority() returns incorrect value X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2005 18:37:29 -0000 On Thu, 9 Jun 2005, Andriy Gapon wrote: > on 09.06.2005 16:17 Bruce Evans said the following: >>> on 08.06.2005 23:49 Maxim Sobolev said the following: >>>> Committed, thanks! >>>> >>>> I wonder if the setpriority(2) needs the same cure. Please clarify and >>>> let me know. I'll keep the PR open till your reply. >> >> I wonder why committers commit patches without fully understanding them. > > I wonder if you fully understood the patch, the issue and the > getriority/setpriority. I thought I did, but I read POSIX partly backwards. >> POSIX specifies that the non-error range of values returned by >> getpriority() >> is [0, 2*{NZERO}-1]; -1 is the error indicator. Applications must subtract >> NZERO to get the actual priority value. > I think you have misread POSIX specification and you are confusing two > things: (1) priority - priority inside the blackbox that schedules > processes versus values that should be passed to setpriotiy() and > returned from getpriority(); (2) syscall internal implementation versus > user-visible libc function. Priority in the black bix is td->td_priority. p->p_nice is supposed to be the user-visible priority offset by NZERO in freeBSD, and it is, but things are made confusing by "fixing" the historical value of NZERO so that NZERO is 0. Biases of 0 are subtle and POSIX has made the NZERO = 0 bias by wrong over-specifying the behaviour as the historical behaviour. > Regaridng #1, here's a direct quote: > http://www.opengroup.org/onlinepubs/009695399/functions/getpriority.html > > "Upon successful completion, getpriority() shall return an integer in > the range -{NZERO} to {NZERO}-1. Otherwise, -1 shall be returned and > errno set to indicate the error." > Also: > "The getpriority() and setpriority() functions work with an offset nice > value (nice value -{NZERO}). The nice value is in the range [0,2*{NZERO} > -1], while the return value for getpriority() and the third parameter > for setpriority() are in the range [-{NZERO},{NZERO} -1]." This is the part that I misread. I only saw the "Also" part and I read it backwards as specifying Linux-like behaviour to avoid the in-band ierror indicator. > So this is a difference between priority as it is seen in user-land > (above libc layer) and priority inside the POSIX blackbox of OS (the one > in [0,2*{NZERO} -1] range). It is a bug in POSIX for POSIX to specify the black box. The FreeBSD black box doesn't actually use this range, and applications and users hardly notice since they mostly see the adjusted priorities (with default priority 0 instead of NZERO). > My understanding is that FreeBSD and Linux are very close to POSIXly > correct implemetations with NZERO=20. In fact, Linux's implementation is > completely compliant and FreeBSD allows +20 which is beyond the POSIX range. > Also, -1 return value from getpriority() is a problematic point of POSIX > specification not implemenations. To conform, FreeBSD would need to expand or shrink the priority range by 1 to cover or drop +20, and change NZERO from 0 to 20 or 21, and move the priorities in the grey box up by NZERO. > Regarding #2, both FreeBSD and Linux in their unique ways correctly > return errno/priority level from kernel-land to user-land. FreeBSD > syscall returns priority already in [-{NZERO},{NZERO} -1] range; Linux Except NZERO is 0 in FreeBSD. > syscall returns priority in [1,2*{NZERO}] range and with reversed > comparison, and then (g)libc stub of getpritority performs 20-X > conversion to return a correct value to application. >> I think the reason that setpriority(2) is not affected is actually that >> Linux applications know to use (20 - pri) to recover the actual priority. It is actually the library stub that does this. So getpriority(2) doesn't give POSIX getpriority in Linux, but getpriority() 3 does. >> Fixing getpriority() in FreeBSD and all emulators should involve much the >> same code: map the range of internal priorities [PRIO_MIN, PRIO_MAX] to >> getpriority()'s range [0, 2*{SUBSYSTEM_SPECIFIC_NZERO}-1] as linearly >> as possible (something like: >> >> pri |-> (pri - PRIO_MIN) * (2 * SUBSYSTEM_SPECIFIC_NZERO - 1) / >> (PRIO_MAX - PRIO_MIN) >> >> but more complicated, since for if SUBSYSTEM_SPECIFIC_NZERO == 20 the >> above maps the default priority 0 to (20 * 39 / 2) = 19, but 20 is >> required; also for Linux there must be a negation. > > I think you have greatly overcomplicated thing sbecause of your original > misunderstanding. Just compile a small program using > getpriority/setpriority for FreeBSD, Linux and any other Unix avaialble > to you, run it and you will see how simple thingx are in reality and > that NZERO is not visible to userland. Read the man pages too. > Yes, and try Linux emulation with and without my patch to understand > what the problem with emualtion really is. This part of my previous mail is almost correct. There is an internal range [PRIO_MIN, PRIO_MAX] which should be mapped to the [-{NZERO}, {NZERO} -1] range (not the [0, 2*{NZERO} - 1] range like I said previously. setpriority() should invert this mapping. Matching the range of the emulated system is actually more important for setpriority(), since applications probably treat values returned by getpriority() as cookies and don't notice if they are out of bounds, but the kernel does range checking on the values passed by setpriority(). In addition, for Linux getpriority() the values must be mapped by pri |-> 20 - pri so that the library stub can restore the previous values. The magic 20 is spelled 20 in the Linux kernel (2.6.10 at least) and as PZERO in glibc (2.3.2 at least). This secondary mapping makes scaling in the first mapping more important, since if FreeBSD had +21 in its priority range, then 20 - pri would give a value of -1 and the library stub would conider this to be an error. Summary: I don't like the committed version since it has many subtle magic numbers in its 20 - X formula: 20: part of Linux adjustment. 20 = 1 + Linux's maximum priority. -1: another part of Linux adjustment 1: factor of 20/20 for the scaling step, where the first 20 is what should be Linux's NZERO and the second 20 is what should be FreeBSD's NZERO (= (PRIO_MAX - PRIO_MIN) / 2). Note that these 20's are subtly different from the 20 in Linux's adjustment. 0: bias for the scaling step (= FreeBSD NZERO). Bruce From owner-freebsd-emulation@FreeBSD.ORG Sat Jun 11 18:40:10 2005 Return-Path: X-Original-To: freebsd-emulation@hub.freebsd.org Delivered-To: freebsd-emulation@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6E9CD16A41C for ; Sat, 11 Jun 2005 18:40:10 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3396043D49 for ; Sat, 11 Jun 2005 18:40:10 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j5BIe8Xa072872 for ; Sat, 11 Jun 2005 18:40:08 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j5BIe8nO072871; Sat, 11 Jun 2005 18:40:08 GMT (envelope-from gnats) Date: Sat, 11 Jun 2005 18:40:08 GMT Message-Id: <200506111840.j5BIe8nO072871@freefall.freebsd.org> To: freebsd-emulation@FreeBSD.org From: Bruce Evans Cc: Subject: Re: kern/81951: [patch] linux emulation: getpriority() returns incorrect value X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Bruce Evans List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2005 18:40:10 -0000 The following reply was made to PR kern/81951; it has been noted by GNATS. From: Bruce Evans To: Andriy Gapon Cc: freebsd-gnats-submit@freebsd.org, freebsd-emulation@freebsd.org Subject: Re: kern/81951: [patch] linux emulation: getpriority() returns incorrect value Date: Sun, 12 Jun 2005 04:37:24 +1000 (EST) On Thu, 9 Jun 2005, Andriy Gapon wrote: > on 09.06.2005 16:17 Bruce Evans said the following: >>> on 08.06.2005 23:49 Maxim Sobolev said the following: >>>> Committed, thanks! >>>> >>>> I wonder if the setpriority(2) needs the same cure. Please clarify and >>>> let me know. I'll keep the PR open till your reply. >> >> I wonder why committers commit patches without fully understanding them. > > I wonder if you fully understood the patch, the issue and the > getriority/setpriority. I thought I did, but I read POSIX partly backwards. >> POSIX specifies that the non-error range of values returned by >> getpriority() >> is [0, 2*{NZERO}-1]; -1 is the error indicator. Applications must subtract >> NZERO to get the actual priority value. > I think you have misread POSIX specification and you are confusing two > things: (1) priority - priority inside the blackbox that schedules > processes versus values that should be passed to setpriotiy() and > returned from getpriority(); (2) syscall internal implementation versus > user-visible libc function. Priority in the black bix is td->td_priority. p->p_nice is supposed to be the user-visible priority offset by NZERO in freeBSD, and it is, but things are made confusing by "fixing" the historical value of NZERO so that NZERO is 0. Biases of 0 are subtle and POSIX has made the NZERO = 0 bias by wrong over-specifying the behaviour as the historical behaviour. > Regaridng #1, here's a direct quote: > http://www.opengroup.org/onlinepubs/009695399/functions/getpriority.html > > "Upon successful completion, getpriority() shall return an integer in > the range -{NZERO} to {NZERO}-1. Otherwise, -1 shall be returned and > errno set to indicate the error." > Also: > "The getpriority() and setpriority() functions work with an offset nice > value (nice value -{NZERO}). The nice value is in the range [0,2*{NZERO} > -1], while the return value for getpriority() and the third parameter > for setpriority() are in the range [-{NZERO},{NZERO} -1]." This is the part that I misread. I only saw the "Also" part and I read it backwards as specifying Linux-like behaviour to avoid the in-band ierror indicator. > So this is a difference between priority as it is seen in user-land > (above libc layer) and priority inside the POSIX blackbox of OS (the one > in [0,2*{NZERO} -1] range). It is a bug in POSIX for POSIX to specify the black box. The FreeBSD black box doesn't actually use this range, and applications and users hardly notice since they mostly see the adjusted priorities (with default priority 0 instead of NZERO). > My understanding is that FreeBSD and Linux are very close to POSIXly > correct implemetations with NZERO=20. In fact, Linux's implementation is > completely compliant and FreeBSD allows +20 which is beyond the POSIX range. > Also, -1 return value from getpriority() is a problematic point of POSIX > specification not implemenations. To conform, FreeBSD would need to expand or shrink the priority range by 1 to cover or drop +20, and change NZERO from 0 to 20 or 21, and move the priorities in the grey box up by NZERO. > Regarding #2, both FreeBSD and Linux in their unique ways correctly > return errno/priority level from kernel-land to user-land. FreeBSD > syscall returns priority already in [-{NZERO},{NZERO} -1] range; Linux Except NZERO is 0 in FreeBSD. > syscall returns priority in [1,2*{NZERO}] range and with reversed > comparison, and then (g)libc stub of getpritority performs 20-X > conversion to return a correct value to application. >> I think the reason that setpriority(2) is not affected is actually that >> Linux applications know to use (20 - pri) to recover the actual priority. It is actually the library stub that does this. So getpriority(2) doesn't give POSIX getpriority in Linux, but getpriority() 3 does. >> Fixing getpriority() in FreeBSD and all emulators should involve much the >> same code: map the range of internal priorities [PRIO_MIN, PRIO_MAX] to >> getpriority()'s range [0, 2*{SUBSYSTEM_SPECIFIC_NZERO}-1] as linearly >> as possible (something like: >> >> pri |-> (pri - PRIO_MIN) * (2 * SUBSYSTEM_SPECIFIC_NZERO - 1) / >> (PRIO_MAX - PRIO_MIN) >> >> but more complicated, since for if SUBSYSTEM_SPECIFIC_NZERO == 20 the >> above maps the default priority 0 to (20 * 39 / 2) = 19, but 20 is >> required; also for Linux there must be a negation. > > I think you have greatly overcomplicated thing sbecause of your original > misunderstanding. Just compile a small program using > getpriority/setpriority for FreeBSD, Linux and any other Unix avaialble > to you, run it and you will see how simple thingx are in reality and > that NZERO is not visible to userland. Read the man pages too. > Yes, and try Linux emulation with and without my patch to understand > what the problem with emualtion really is. This part of my previous mail is almost correct. There is an internal range [PRIO_MIN, PRIO_MAX] which should be mapped to the [-{NZERO}, {NZERO} -1] range (not the [0, 2*{NZERO} - 1] range like I said previously. setpriority() should invert this mapping. Matching the range of the emulated system is actually more important for setpriority(), since applications probably treat values returned by getpriority() as cookies and don't notice if they are out of bounds, but the kernel does range checking on the values passed by setpriority(). In addition, for Linux getpriority() the values must be mapped by pri |-> 20 - pri so that the library stub can restore the previous values. The magic 20 is spelled 20 in the Linux kernel (2.6.10 at least) and as PZERO in glibc (2.3.2 at least). This secondary mapping makes scaling in the first mapping more important, since if FreeBSD had +21 in its priority range, then 20 - pri would give a value of -1 and the library stub would conider this to be an error. Summary: I don't like the committed version since it has many subtle magic numbers in its 20 - X formula: 20: part of Linux adjustment. 20 = 1 + Linux's maximum priority. -1: another part of Linux adjustment 1: factor of 20/20 for the scaling step, where the first 20 is what should be Linux's NZERO and the second 20 is what should be FreeBSD's NZERO (= (PRIO_MAX - PRIO_MIN) / 2). Note that these 20's are subtly different from the 20 in Linux's adjustment. 0: bias for the scaling step (= FreeBSD NZERO). Bruce