From owner-freebsd-emulation@FreeBSD.ORG Mon Jun 13 12:40:25 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 F388916A41F for ; Mon, 13 Jun 2005 12:40:24 +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 7457F43D68 for ; Mon, 13 Jun 2005 12: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 j5DCeFT6062549 for ; Mon, 13 Jun 2005 12: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 j5DCeF18062548; Mon, 13 Jun 2005 12:40:15 GMT (envelope-from gnats) Date: Mon, 13 Jun 2005 12:40:15 GMT Message-Id: <200506131240.j5DCeF18062548@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: Mon, 13 Jun 2005 12:40:25 -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: Mon, 13 Jun 2005 15:34:20 +0300 on 11.06.2005 21:37 Bruce Evans said the following: > 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, I agree with your reasoning and description of the situation. Yes, "20-X" formula would be broken if there are any significant changes in Linux or FreeBSD kernels with respect to process priorities. Unfortunately I can not promise to do any work to make this conversion more proper, so I suggest that we keep 20-X plus, maybe, /*XXX*/ comment until somebody makes it perfect. Having no conversion would be (was!) worse, I think. Returning to a more general level, I also agree with you that POSIX should specify only interfaces and it is very strange that they talk about some internal states; they made things more confusing while perhaps trying to explain them better. I found the following note in AIX man page: http://publib16.boulder.ibm.com/doc_link/en_US/a_doc_lib/libs/basetrf1/basetrf1tfrm.htm Process priorities in AT&T System V are defined in the range of 0 to 39, rather than -20 to 20 as in BSD, and the nice library routine is supported by both. Accordingly, two versions of the nice are supported by AIX Version 3. The default version behaves like the AT&T System V version, with the Increment parameter treated as the modifier of a value in the range of 0 to 39 (0 corresponds to -20, 39 corresponds to 9, and priority 20 is not reachable with this interface). If I read this correctly, POSIX authors tried to cater to both worlds, so they designed (or merely described) something that has an interface close to BSD internals while talking about mapping it to SysV internals. Having historical nice(2) system call has probably also added its share of complexity. As to the [-20,+20] range, I see in HP-UX, Solaris and AIX man pages that they also have this range. Seems that BSD won over POSIX (and SysV) in this case. -- Andriy Gapon