From owner-freebsd-arch@freebsd.org Sun Feb 18 06:25:10 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 362EFF15D69 for ; Sun, 18 Feb 2018 06:25:10 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id C38A6853E1 for ; Sun, 18 Feb 2018 06:25:09 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: by mailman.ysv.freebsd.org (Postfix) id 819C8F15D68; Sun, 18 Feb 2018 06:25:09 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5F649F15D66 for ; Sun, 18 Feb 2018 06:25:09 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [45.55.20.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F3B9C853E0 for ; Sun, 18 Feb 2018 06:25:08 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from localhost ([127.0.0.1] helo=id.bluezbox.com) by id.bluezbox.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89 (FreeBSD)) (envelope-from ) id 1enIPJ-0000to-8f for arch@freebsd.org; Sat, 17 Feb 2018 22:25:06 -0800 Received: (from gonzo@localhost) by id.bluezbox.com (8.15.2/8.15.2/Submit) id w1I6P4i7003459 for arch@freebsd.org; Sat, 17 Feb 2018 22:25:04 -0800 (PST) (envelope-from gonzo@bluezbox.com) X-Authentication-Warning: id.bluezbox.com: gonzo set sender to gonzo@bluezbox.com using -f Date: Sat, 17 Feb 2018 22:25:04 -0800 From: Oleksandr Tymoshenko To: arch@freebsd.org Subject: Inconsistencies in OF_* functions return values Message-ID: <20180218062504.GA3226@bluezbox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: FreeBSD/11.1-RELEASE-p4 (amd64) User-Agent: Mutt/1.9.1 (2017-09-22) X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: Hello, I've been writing documentation for Open Firmware API (OF_* functions) and found some inconsistencies. As far as I understand OF_* functions are used to access device tree in abstract way and mostly serve as wrappers to methods in concrete implementations. There are two implementations at the moment: s [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Feb 2018 06:25:10 -0000 Hello, I've been writing documentation for Open Firmware API (OF_* functions) and found some inconsistencies. As far as I understand OF_* functions are used to access device tree in abstract way and mostly serve as wrappers to methods in concrete implementations. There are two implementations at the moment: standard Open Firmware and FDT. Nodes in device tree represented by opaque integer type phandle_t. So whenever function should return reference to the node it returns phandle_t value. The problem is that error reporting is not consistent across concrete implementations. Just as error checks in API consumer code. Standard Open Firmware implementations of tree navigations functions OF_peer, OF_child, OF_parent return -1 in case of internal error and just passes value returned by succefull call to firmware. FDT implementations return 0 to indicate both errors and absense of requested node. OF_finddevice in Standard OF acts like navigation functions: -1 and pass through. OF_finddevice in FDT returns -1 both on error and if path can't be found. API consumers of navigation functions are more or less consistently check for 0. There are two code instances that check for -1. API consumers for OF_finddevice are all over the place. Some check for 0, some for -1, some for both. Also phandle_t is uint32_t so consumer code can't be just converted to if (node > 0) ... I didn't find any reserved values for phandle in FDT specification [1]. The only requirement for it is to be unique within device tree. So in theory 0 is also valid phandle_t. In practice both GNU dtc and our own dtc start numbering nodes from 1. I think the right way to fix this is to consistently use 0 to indicate error or "no node" situation. I don't have enough historical insight about OpenFirmware to claim that this approach is compatible with older standards. I'd appreciate input on this topic from people who actually work with non-FDT implementation of OF_ API. [1] https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.2 -- gonzo From owner-freebsd-arch@freebsd.org Sun Feb 18 15:14:39 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B6DFBF100BB for ; Sun, 18 Feb 2018 15:14:38 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DB8E7B967 for ; Sun, 18 Feb 2018 15:14:37 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from comporellon.tachypleus.net (cpe-75-82-218-62.socal.res.rr.com [75.82.218.62]) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id w1IFETpU012994 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Sun, 18 Feb 2018 07:14:30 -0800 Subject: Re: Inconsistencies in OF_* functions return values To: freebsd-arch@freebsd.org References: <20180218062504.GA3226@bluezbox.com> From: Nathan Whitehorn Message-ID: <7c4cabad-421c-63db-bf31-289cf4b57fd1@freebsd.org> Date: Sun, 18 Feb 2018 07:14:29 -0800 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180218062504.GA3226@bluezbox.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Sonic-CAuth: UmFuZG9tSVZGnuK9IPA3CiErg/qUlXAeH3HWWF3Rg3qYtKf9vVxVawMPD05z620TIC2oR2Ch3MFEtFfn96bEGWNbxBPAksUmtkEvTu4ySBk= X-Sonic-ID: C;Bttlar4U6BGagVDNXaHR5A== M;HO3Tar4U6BGagVDNXaHR5A== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Feb 2018 15:14:39 -0000 On 02/17/18 22:25, Oleksandr Tymoshenko wrote: > Hello, > > I've been writing documentation for Open Firmware API > (OF_* functions) and found some inconsistencies. Thank you! > As far as I understand OF_* functions are used to access device > tree in abstract way and mostly serve as wrappers to methods in > concrete implementations. There are two implementations at the > moment: standard Open Firmware and FDT. Nodes in device tree > represented by opaque integer type phandle_t. So whenever > function should return reference to the node it returns phandle_t > value. The problem is that error reporting is not consistent > across concrete implementations. Just as error checks in API > consumer code. Some of the error checks are indeed a mess, but I think the implementations are right. For reference, all of our OF_* functions are supposed to match the IEEE 1275 CI specification (page 64 and on). Insofar as that is different from FDT, we wrap the FDT conventions (including the definition of phandle) to match the 1275 ones. > Standard Open Firmware implementations of tree navigations > functions OF_peer, OF_child, OF_parent return -1 in case of > internal error and just passes value returned by succefull call > to firmware. > FDT implementations return 0 to indicate both errors and absense > of requested node. OF_peer, child and, and parent are defined to return 0 on failure and a non-zero number otherwise, so FDT is right. The standard does not allow an "internal error" value. We should adjust ofw_standard and ofw_real to return 0 if this occurs (which never happens in practice). > OF_finddevice in Standard OF acts like navigation functions: > -1 and pass through. > > OF_finddevice in FDT returns -1 both on error and if path > can't be found. These are the same correct behavior: OF_finddevice() is defined to return -1 on failure of any kind. (On real OF, the firmware returns this if the path cannot be found.) > > API consumers of navigation functions are more or less > consistently check for 0. There are two code instances > that check for -1. > > API consumers for OF_finddevice are all over the place. > Some check for 0, some for -1, some for both. I assume only very few check for zero? Those can't work at present. > Also phandle_t is uint32_t so consumer code can't be just > converted to if (node > 0) ... This can't be avoided, sadly. You have to compare to (phandle_t)-1 to be compliant with the standard. > I didn't find any reserved values for phandle in FDT > specification [1]. The only requirement for it is to be unique > within device tree. So in theory 0 is also valid phandle_t. > In practice both GNU dtc and our own dtc start numbering > nodes from 1. FDT "phandles" are our "xref phandles" and have no constraints on numeric value. Our phandles, which cannot be zero or -1, are the FDT offsets shifted to make 0 an invalid value. > I think the right way to fix this is to consistently use 0 > to indicate error or "no node" situation. I don't have > enough historical insight about OpenFirmware to claim > that this approach is compatible with older standards. > I'd appreciate input on this topic from people who actually > work with non-FDT implementation of OF_ API. > > [1] https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.2 > I think this is not the right approach and will break a lot of code. We should keep using the 1275 CI values, which we almost entirely already are. -Nathan From owner-freebsd-arch@freebsd.org Sun Feb 18 16:19:51 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E24A0F15614 for ; Sun, 18 Feb 2018 16:19:50 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) Received: from sonic305-20.consmr.mail.gq1.yahoo.com (sonic305-20.consmr.mail.gq1.yahoo.com [98.137.64.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6695F7E40E for ; Sun, 18 Feb 2018 16:19:50 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) X-YMail-OSG: abr1hnUVM1lueGDRlW3uCclJnKNbTLRmIGA_iqBcqAFay0zp9DnurjDwBmjgY8l rdaEVTF1p7I8SKGbBHYv6fndMbrNkk3CvnAQC8UuXXhlDsl2H6zQKa25T9VGCqEVKSjc7.c1G4KN ueySvZADEIXKTfDTBX5IXHz5NR6eyPRQ2fKiEhQ40D2FsQ3iMcr3b2hyI9IIg..ZdL.68iOHqgCy leusTkOWbnvQl91DLuEL7cNEPXoxMAjSUIIeK98TlF19cscEGgoyP18czAwz1wYPxYccELDA3oaD .knaoNNtG4SsKe4F95I.PgRjtsrfavb_VdlfKb0_DYs9Y_JqCY75FfBkXhUpnBhHofiP.TCWV7gu 1JHJcLG_YudMfpAuQuFalamoGhzB1c.3yprDGEUXAZKcDkhbZMcvnOHUQPyTY88q7AB81Mwp4XGq G8CaqdO_RR09L1VHyOuZFdZ3iBsYSvn33ENbVx8BVPAiRZ_zBbvtW4Gd4lC6phjzDo5TJSG29w06 gsfJTdA-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Sun, 18 Feb 2018 16:19:43 +0000 Received: from smtp102.rhel.mail.gq1.yahoo.com (EHLO [192.168.1.25]) ([216.39.57.211]) by smtp405.mail.gq1.yahoo.com (JAMES SMTP Server ) with ESMTPA ID df19846b25553296f2617b585d840d53; Sun, 18 Feb 2018 15:59:29 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: ps output line length change Message-Id: <4D983C5E-C19A-4B0E-AABA-C21DA89FD833@yahoo.com> Date: Sun, 18 Feb 2018 07:59:28 -0800 To: "Rodney W. Grimes" , freebsd-arch@freebsd.org X-Mailer: Apple Mail (2.3445.5.20) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Feb 2018 16:19:51 -0000 Rodney W. Grimes freebsd-rwg at pdx.rh.CN85.dnsmgr.net wrote on Sat Feb 17 21:12:25 UTC 2018 : > We already ahve the whole linuxlator thing, if they want a linux > ps cant they just.. um actually use a linux ps from /compat/linux? > I know ps grovels around in a lot of internals but this would, > imho, be the route to persue a "linux compatible" ps output. How many processor architectures for FreeBSD does the "linuxlator" cover vs. not cover? Which ones? (Not that I'm after linux compatible command variants. I just use powerpc64, powerpc, arm64, and armv7 --in addition to amd64.) === Mark Millard marklmi at yahoo.com ( markmi at dsl-only.net is going away in 2018-Feb, late) From owner-freebsd-arch@freebsd.org Sun Feb 18 20:14:00 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7B343F26C16 for ; Sun, 18 Feb 2018 20:14:00 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [45.55.20.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1B69868F96; Sun, 18 Feb 2018 20:13:59 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from localhost ([127.0.0.1] helo=id.bluezbox.com) by id.bluezbox.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89 (FreeBSD)) (envelope-from ) id 1enVLL-0004D8-J9; Sun, 18 Feb 2018 12:13:52 -0800 Received: (from gonzo@localhost) by id.bluezbox.com (8.15.2/8.15.2/Submit) id w1IKDoee016189; Sun, 18 Feb 2018 12:13:50 -0800 (PST) (envelope-from gonzo@bluezbox.com) X-Authentication-Warning: id.bluezbox.com: gonzo set sender to gonzo@bluezbox.com using -f Date: Sun, 18 Feb 2018 12:13:50 -0800 From: Oleksandr Tymoshenko To: Nathan Whitehorn Cc: freebsd-arch@freebsd.org Subject: Re: Inconsistencies in OF_* functions return values Message-ID: <20180218201350.GA15860@bluezbox.com> References: <20180218062504.GA3226@bluezbox.com> <7c4cabad-421c-63db-bf31-289cf4b57fd1@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7c4cabad-421c-63db-bf31-289cf4b57fd1@freebsd.org> X-Operating-System: FreeBSD/11.1-RELEASE-p4 (amd64) User-Agent: Mutt/1.9.1 (2017-09-22) X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: Nathan Whitehorn (nwhitehorn@freebsd.org) wrote: > > > On 02/17/18 22:25, Oleksandr Tymoshenko wrote: > > Hello, > > > > I've been writing documentation for Open Firmware API > > (OF_* functions) and [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Feb 2018 20:14:00 -0000 Nathan Whitehorn (nwhitehorn@freebsd.org) wrote: > > > On 02/17/18 22:25, Oleksandr Tymoshenko wrote: > > Hello, > > > > I've been writing documentation for Open Firmware API > > (OF_* functions) and found some inconsistencies. > > Thank you! > > > As far as I understand OF_* functions are used to access device > > tree in abstract way and mostly serve as wrappers to methods in > > concrete implementations. There are two implementations at the > > moment: standard Open Firmware and FDT. Nodes in device tree > > represented by opaque integer type phandle_t. So whenever > > function should return reference to the node it returns phandle_t > > value. The problem is that error reporting is not consistent > > across concrete implementations. Just as error checks in API > > consumer code. > > Some of the error checks are indeed a mess, but I think the > implementations are right. For reference, all of our OF_* functions are > supposed to match the IEEE 1275 CI specification (page 64 and on). > Insofar as that is different from FDT, we wrap the FDT conventions > (including the definition of phandle) to match the 1275 ones. > > > Standard Open Firmware implementations of tree navigations > > functions OF_peer, OF_child, OF_parent return -1 in case of > > internal error and just passes value returned by succefull call > > to firmware. > > FDT implementations return 0 to indicate both errors and absense > > of requested node. > > OF_peer, child and, and parent are defined to return 0 on failure and a > non-zero number otherwise, so FDT is right. The standard does not allow > an "internal error" value. We should adjust ofw_standard and ofw_real to > return 0 if this occurs (which never happens in practice). > > > OF_finddevice in Standard OF acts like navigation functions: > > -1 and pass through. > > > > OF_finddevice in FDT returns -1 both on error and if path > > can't be found. > > These are the same correct behavior: OF_finddevice() is defined to > return -1 on failure of any kind. (On real OF, the firmware returns this > if the path cannot be found.) > > > > > API consumers of navigation functions are more or less > > consistently check for 0. There are two code instances > > that check for -1. > > > > API consumers for OF_finddevice are all over the place. > > Some check for 0, some for -1, some for both. > > I assume only very few check for zero? Those can't work at present. There are 14 instances of checks for 0 in sys/arm I could find with grep. I believe they're mostly safeguards against invalid dtb files so failure path never taken in practice. > > Also phandle_t is uint32_t so consumer code can't be just > > converted to if (node > 0) ... > > This can't be avoided, sadly. You have to compare to (phandle_t)-1 to be > compliant with the standard. In this case we need some kind of define, like INVALID_PHANDLE. Or OF_valid() function. Because phandle_t is opaque type and seeing -1 as a possible return value it's natural to assume that it's signed and implement something like "if (node > 0)". > > I didn't find any reserved values for phandle in FDT > > specification [1]. The only requirement for it is to be unique > > within device tree. So in theory 0 is also valid phandle_t. > > In practice both GNU dtc and our own dtc start numbering > > nodes from 1. > > FDT "phandles" are our "xref phandles" and have no constraints on > numeric value. Our phandles, which cannot be zero or -1, are the FDT > offsets shifted to make 0 an invalid value. Ah. It makes more sense now. Thanks. This should be documented too :) > > I think the right way to fix this is to consistently use 0 > > to indicate error or "no node" situation. I don't have > > enough historical insight about OpenFirmware to claim > > that this approach is compatible with older standards. > > I'd appreciate input on this topic from people who actually > > work with non-FDT implementation of OF_ API. > > > > [1] https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.2 > > > > I think this is not the right approach and will break a lot of code. We > should keep using the 1275 CI values, which we almost entirely already are. I agree. I didn't have information about IEEE 1275 standard. -- gonzo From owner-freebsd-arch@freebsd.org Mon Feb 19 15:55:28 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C9429F0ACAF for ; Mon, 19 Feb 2018 15:55:27 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5F7427BE4C for ; Mon, 19 Feb 2018 15:55:26 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from comporellon.tachypleus.net (cpe-75-82-218-62.socal.res.rr.com [75.82.218.62]) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id w1JFtHHA018030 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 19 Feb 2018 07:55:17 -0800 Subject: Re: Inconsistencies in OF_* functions return values To: Oleksandr Tymoshenko Cc: freebsd-arch@freebsd.org References: <20180218062504.GA3226@bluezbox.com> <7c4cabad-421c-63db-bf31-289cf4b57fd1@freebsd.org> <20180218201350.GA15860@bluezbox.com> From: Nathan Whitehorn Message-ID: <8a18fd5f-8734-8323-7638-039b5b2b5876@freebsd.org> Date: Mon, 19 Feb 2018 07:55:17 -0800 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180218201350.GA15860@bluezbox.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Sonic-CAuth: UmFuZG9tSVZnS87YbJ2A3GBRvDccZcVtaT/pGqT+eRUklBVBHXcVB6yu0lpYvXHLUlz2oILh7OieSTMX3bofB4vl9exMLYUVhUkb+vSSRWA= X-Sonic-ID: C;StPHR40V6BGPD1DNXaHR5A== M;UJL4R40V6BGPD1DNXaHR5A== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 15:55:28 -0000 On 02/18/18 12:13, Oleksandr Tymoshenko wrote: > Nathan Whitehorn (nwhitehorn@freebsd.org) wrote: >> >> On 02/17/18 22:25, Oleksandr Tymoshenko wrote: >>> Hello, >>> >>> I've been writing documentation for Open Firmware API >>> (OF_* functions) and found some inconsistencies. >> Thank you! >> >>> As far as I understand OF_* functions are used to access device >>> tree in abstract way and mostly serve as wrappers to methods in >>> concrete implementations. There are two implementations at the >>> moment: standard Open Firmware and FDT. Nodes in device tree >>> represented by opaque integer type phandle_t. So whenever >>> function should return reference to the node it returns phandle_t >>> value. The problem is that error reporting is not consistent >>> across concrete implementations. Just as error checks in API >>> consumer code. >> Some of the error checks are indeed a mess, but I think the >> implementations are right. For reference, all of our OF_* functions are >> supposed to match the IEEE 1275 CI specification (page 64 and on). >> Insofar as that is different from FDT, we wrap the FDT conventions >> (including the definition of phandle) to match the 1275 ones. >> >>> Standard Open Firmware implementations of tree navigations >>> functions OF_peer, OF_child, OF_parent return -1 in case of >>> internal error and just passes value returned by succefull call >>> to firmware. >>> FDT implementations return 0 to indicate both errors and absense >>> of requested node. >> OF_peer, child and, and parent are defined to return 0 on failure and a >> non-zero number otherwise, so FDT is right. The standard does not allow >> an "internal error" value. We should adjust ofw_standard and ofw_real to >> return 0 if this occurs (which never happens in practice). I've fixed these. >>> OF_finddevice in Standard OF acts like navigation functions: >>> -1 and pass through. >>> >>> OF_finddevice in FDT returns -1 both on error and if path >>> can't be found. >> These are the same correct behavior: OF_finddevice() is defined to >> return -1 on failure of any kind. (On real OF, the firmware returns this >> if the path cannot be found.) >> >>> API consumers of navigation functions are more or less >>> consistently check for 0. There are two code instances >>> that check for -1. >>> >>> API consumers for OF_finddevice are all over the place. >>> Some check for 0, some for -1, some for both. >> I assume only very few check for zero? Those can't work at present. > There are 14 instances of checks for 0 in sys/arm I could find with > grep. I believe they're mostly safeguards against invalid dtb > files so failure path never taken in practice. Fascinating. Well, those should be easy to fix and is a sure sign of how important the documentation you are writing is. > >>> Also phandle_t is uint32_t so consumer code can't be just >>> converted to if (node > 0) ... >> This can't be avoided, sadly. You have to compare to (phandle_t)-1 to be >> compliant with the standard. > In this case we need some kind of define, like INVALID_PHANDLE. > Or OF_valid() function. Because phandle_t is opaque type and > seeing -1 as a possible return value it's natural to assume > that it's signed and implement something like "if (node > 0)". Yes, could. It is irritating that the standard defines a mixture of -1 and 0 returns, so I have a small worry that this would encourage people to check the results of OF_peer(), OF_parent(), and OF_child() against INVALID_PHANDLE. I am not sure what the lesser evil is and will defer to your judgment. > >>> I didn't find any reserved values for phandle in FDT >>> specification [1]. The only requirement for it is to be unique >>> within device tree. So in theory 0 is also valid phandle_t. >>> In practice both GNU dtc and our own dtc start numbering >>> nodes from 1. >> FDT "phandles" are our "xref phandles" and have no constraints on >> numeric value. Our phandles, which cannot be zero or -1, are the FDT >> offsets shifted to make 0 an invalid value. > Ah. It makes more sense now. Thanks. This should be documented too :) Yes, no doubt! It is unfortunate, if understandable in context, that the FDT people reused this term in a partially-overlapping way. > >>> I think the right way to fix this is to consistently use 0 >>> to indicate error or "no node" situation. I don't have >>> enough historical insight about OpenFirmware to claim >>> that this approach is compatible with older standards. >>> I'd appreciate input on this topic from people who actually >>> work with non-FDT implementation of OF_ API. >>> >>> [1] https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.2 >>> >> I think this is not the right approach and will break a lot of code. We >> should keep using the 1275 CI values, which we almost entirely already are. > I agree. I didn't have information about IEEE 1275 standard. > Let me know if you need any help on this. -Nathan From owner-freebsd-arch@freebsd.org Mon Feb 19 20:05:10 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0EB42F1FE36 for ; Mon, 19 Feb 2018 20:05:10 +0000 (UTC) (envelope-from milstar2@protonmail.com) Received: from mail3.protonmail.ch (mail3.protonmail.ch [185.70.40.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.protonmail.ch", Issuer "QuoVadis Global SSL ICA G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8F75968A1A for ; Mon, 19 Feb 2018 20:05:09 +0000 (UTC) (envelope-from milstar2@protonmail.com) Date: Mon, 19 Feb 2018 14:56:23 -0500 To: "freebsd-arch@freebsd.org" From: milstar2 Reply-To: milstar2 Subject: browsers test -conkeror, dooble-2018 , surf, uzbl, qutebrowser-2018 , qupzilla, firefox60, tor8, firefox52.6-esr 2018 Message-ID: Feedback-ID: n5BNh_e6aeHBk-I8FU0cGocxL37gS2UcFrw4Zwx3ST-Wj1zVjXnXI51HnHwgUkEq3yNqR4cgJQK06bJZ5C2beQ==:Ext:ProtonMail MIME-Version: 1.0 X-Spam-Status: No, score=-0.6 required=5.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM, FREEMAIL_REPLYTO_END_DIGIT,HTML_MESSAGE autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail.protonmail.ch Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 20:05:10 -0000 RG9vYmxlICAtaG93IGNhbiBkaXNhYmxlICAxIHJvdyA/CjEgcm93ICArICB0aXRsZSBvZiB3aW5k b3dzICAtbm8gYW55IGRlbWFuZCBmb3IgMSByb3cgLApjYW4gbWFkZSBzbWFsbCBpY29ucyBpbiAy IHJvdyAsbm8gZGVtYW5kIGZvciBsb25nIGFkcmVzcyBiYXIKMnJvdyAgIDwgPiByZWxvYWQgYWRy ZXNzIGJhcihub3QgdmVyeWxvbmcpICsgc21hbGwgaWNvbnMgZm9yIHdpbmRvd3MgLAoKa2FsaTIw MTggdy0wNixERSB4ZmNlNCBkZWxldGVkICxhbGwgdGhlbWUncyxpY29ucyBkZWxldGVkIChmaW5k IC8gLW5hbWUgKmljb24qKSxpbnN0YWxsZWQgd20gb3BlbmJveApvcGVuIDMgeDExICg4MHgyNCks MS0gd2F0Y2ggLW4xIGl3IGRldiB3bGFxbjAgbGluayAsMi10b3AKKzEgd2luZG93ICAxNjB4NDgg d2l0aCBicm93c2VyCgpjbGlwIGZyb20geW91dHViZQpodHRwczovL3d3dy55b3V0dWJlLmNvbS93 YXRjaD92PTJxX3pOMVAwQ0xjCgoxLmNvbmtlcm9yLWFsbCB3b3JrIGZyb20gc3RhcnQgYWZ0ZXIg aW5zdGFsbGF0aW9uICx2ZXJ5IGdvb2Qgc3RhcnR1cCAsbG93ZXN0IGNvbnN1bSAgLApub3QgbW9y ZSAgYXMgMjAwIG1iICB6b3AgYXZhaWwgLm1lbW9yeSBiZWZvcmUgc3RhcnQgIGFuZCBpbiB0aW1l IG9mIHBsYXlpbmcgY2xpcAosWFVMIE1vemlsbGEgLG5vIGRlbWFuZCBmb3IgZXh0cmEgbGliIGRv d25sb2FkaW5nCjIuZG9vYmxlICAgLXNlY29uZCBwbGFjZSAgYXBwcm94IDI1MC0yNjAgbWIgY29u c3VtCjMuIHN1cmYgc291bmQgaW4geXQgcHJlc2VudCAsbm8gdmlkZW8gLGhpZ2ggY29uc3VtICBt b3JlIGFzIDQwMCBtYgo0LiB1emJsICAgLW5vIHZpZGVvIGFuZCBubyBzb3VuZCAgLG5lZWQgcHl0 aG9uICxieSBzZWFyY2ggZHVja2R1Y2tnbyBjb25zdW0gIDEzMC0xNTAgbWIKNS4gcXV0ZWJyb3dz ZXIgIC12aWRlbyAgYW5kIHNvdW5kIGJ5IHl0IHByZXNlbnQgLG5lZWRlIGV4dHJhIGd0azIgLHB5 aHRvbiAgLAogICAgY2FuIGxvZ2luIHRvIGUtbWFpbCAsYnV0IGNhbiB0eXBlIGFueXRoaW5nIC1h c2tlZCBxdWlja21hcmsgLGNvc3VtIGhpZ2gKNi5xdXB6aWxsYSAtYWxsIHdvcmsgLGNvbnN1bSAz MjAtMjUwIG1iCjcuIGZpcmVmb3ggNTIuNiBlc3IgMjAxOCBkZWZhdWx0ICAtd29yc3Qgc3RhcnR1 cCB0aW1lICxtZW1vcnkgY29uc3VtIG1vcmUgaGlnaCBhcyBieSBxdXB6aWxsYQo4LiBmaXJlZm94 IDYwYTEgd2l0aCBkYXkgaXBkYXRlIC1hbGwgd29yayAgICxjb25zdW0gNTUwIG1iCjkudG9yOCBl eHBlcmVtZW50YWwgICAgLWFsbCB3b3JrICA1NTAtNTgwbWIKCiAgUmVsZXZhbnQgY29tbWVudCB3 b3VsZCBhcHByZWNpYXRlZAoKU2VudCB3aXRoIFtQcm90b25NYWlsXShodHRwczovL3Byb3Rvbm1h aWwuY29tKSBTZWN1cmUgRW1haWwu From owner-freebsd-arch@freebsd.org Tue Feb 20 03:02:02 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7F342F1DB0B for ; Tue, 20 Feb 2018 03:02:02 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0FE817C469 for ; Tue, 20 Feb 2018 03:02:02 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-it0-x235.google.com with SMTP id v186so11473761itc.5 for ; Mon, 19 Feb 2018 19:02:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=SW6yxwn8+2DHNC44pZ2x/1lR0nTP3q79J89QRiZHIpw=; b=SFmSsoqU5+VNGLrCItu7cukYlDsukybi9LU3Zi/NX96w8RwDQDZ/AeQCGgzeHANjuc WZ1R9rZEpwPbSVSu4Pzwr/nO5xA36rkJZ2NivTRh+faKytFZXZPPluCTcJD/5baz9Sot LLHDu9eQ1DpkKM+xxn45HckIgUzV7NqrSB+nwMBE5ojMmDdG3jiIlefmiqcyVaop8mbo N8Lr7mKC4Ek1DT8jJIEwxr1B6QJc87oZdE4BaAskbRC9fQhn8hjAhG82FVNw2MLRohzt ji6A4GWrla6HSp89hG5hVhYIw4HvveIwwxGQVweX2/hj338T1qSqE8RF2bO3TpEnmxzR FA1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=SW6yxwn8+2DHNC44pZ2x/1lR0nTP3q79J89QRiZHIpw=; b=Pd/Ygo86DfayyGAcRIWcYkmdgGMyYWGtgZflIDG55tIulvkSld6FddrW6BHzkeEctI hDCd/Zya+wH20MuahzAUrL24Z7jusBdWIcBIX12g6yLv+QJWUokBnVkbSpeeG3rt3NQw 53SFRQPrqn+ijSh8UMSrUdQ8bVQuDW0/eJvai2VkHjZiauYoL/MgVGyZ/7OFjCwnBVch UXz8RdZuK1Otbff/HTsnL15JV+7GGG52BdlAQyc5i5RAB/MPdNNh9l65GLmfXPWeEgD+ oTSLZ08FRGPGxwsxltkpFYc9iIb3yZM8UfcCodB2t5wEWJO8nAGr4J1AGkydiwCUBzyF 351g== X-Gm-Message-State: APf1xPA16vzXmpkFwZpfJxkSkEiv7T5P0GZHEhibvub1sxkPz0t5U994 5cC0KuxFQBVDpQZZS3tNm8FDBKWyvzSqWWivMMI= X-Google-Smtp-Source: AH8x227OMg9b5ivmfIiU4M5ugXGJbUQoqhkX/nkTvba4FM+R4rklEK5bY/9TIDRE59m80kz7oF8jdajmin2DApsWO6A= X-Received: by 10.36.145.1 with SMTP id i1mr18662901ite.54.1519095721470; Mon, 19 Feb 2018 19:02:01 -0800 (PST) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.28.73 with HTTP; Mon, 19 Feb 2018 19:01:41 -0800 (PST) In-Reply-To: <4D983C5E-C19A-4B0E-AABA-C21DA89FD833@yahoo.com> References: <4D983C5E-C19A-4B0E-AABA-C21DA89FD833@yahoo.com> From: Ed Maste Date: Mon, 19 Feb 2018 22:01:41 -0500 X-Google-Sender-Auth: tpaHPxFA0Ky_jZEy48KrQeC-EUY Message-ID: Subject: Re: ps output line length change To: Mark Millard Cc: "Rodney W. Grimes" , "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2018 03:02:02 -0000 On 18 February 2018 at 10:59, Mark Millard via freebsd-arch wrote: > > How many processor architectures for FreeBSD does the "linuxlator" > cover vs. not cover? Which ones? Today the Linuxulator will run i386 Linux binaries on i386, and both i386 and x86_64 Linux binaries on amd64. From owner-freebsd-arch@freebsd.org Tue Feb 20 14:17:03 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2069CF0571E for ; Tue, 20 Feb 2018 14:17:03 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id A4B09790DC for ; Tue, 20 Feb 2018 14:17:02 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 66011F0571A; Tue, 20 Feb 2018 14:17:02 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 41E11F05718 for ; Tue, 20 Feb 2018 14:17:02 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: from mail-ua0-x232.google.com (mail-ua0-x232.google.com [IPv6:2607:f8b0:400c:c08::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D6732790DA; Tue, 20 Feb 2018 14:17:01 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: by mail-ua0-x232.google.com with SMTP id i15so8414662uak.3; Tue, 20 Feb 2018 06:17:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=GVSUbwYCybS6DwrWMFiMsfZ9w3OInjDb/0aKanW6qYc=; b=FFMILo0kaUDbCGBAVZNczw36LQZCSro10qyUDB4n/VKtIiDUmJnn6ywAjFRraEqpnd OWyFkxUSqbp8I9cNPjLNnzOEXgzYEEmuwe1kZa1VfyjmaYi4puM3XD5Kb2xd+vjeHB0A TJvGlh0vTkAx3e89AuJWksSMOp3JoBVOpbKklaBciBLDcZxR9V9e/vdxUpGbNa1uvzuJ 3hGcuJNCLK/lRXSO31kEaVaguXK2xxlh9MdyB0nqL3cB8IL2Ux19CFAKqAF+e4BEjLLn vLr54vXg/YsiCo3v+49wr1Jc5DZJ1C+5YQJ4rAvw0JSx34cHWfAfPDcSs4aDVQJEnMO0 KN6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=GVSUbwYCybS6DwrWMFiMsfZ9w3OInjDb/0aKanW6qYc=; b=iMKU7fXv0HSVg+6mbXVNEttp6mOZghDRtQdqw1Bvos7GA3C22+XZrgepiCa48CoNfS 94gp83DIksL8Tib+hSzBB7/q+aDWLe8bZ/1QVmtRn/Q0vW6fCFj4g+lK0DtvoGsqRRyX e4TxafF5fePn0hVCR+7IQN3Nok/lYwl0JIxjPk/c4MVVAcrzHoIx/GvJCyd+2VLiKZ4p IGIXMmOs15OZc52Eh3u2Lgu2pzIG/6voXw2n3gKTpTQi2B5ApQ+MytKdohru04QRa5n5 4ioGjxEF/tsvwaKugdCF4wdmY08gb/gDuBig/gR2H/f+HxlYBonoDq1MBnhbj/HoXG1I ZMBA== X-Gm-Message-State: APf1xPDDE6hzPrtAzOFpmvBhQt1RaW13NiN7GCWpWcWTav2rPSEDAW03 HG8xMrDuE9ap8wdETeC4tSnmTLLyt8WDNUiFltc= X-Google-Smtp-Source: AH8x2245ibDDeFQtxmuSm31sc3Hb0xXQzOndDK7gsOD95kIJAMGDTghplPSZ1P3R7bid2pqp/qBjC5t7ONk19feUTCw= X-Received: by 10.176.79.150 with SMTP id m22mr10883229uah.131.1519136221431; Tue, 20 Feb 2018 06:17:01 -0800 (PST) MIME-Version: 1.0 Sender: etnapierala@gmail.com Received: by 10.176.7.2 with HTTP; Tue, 20 Feb 2018 06:17:01 -0800 (PST) In-Reply-To: <201802172112.w1HLCI2k069334@pdx.rh.CN85.dnsmgr.net> References: <201802172106.w1HL6hP3045437@slippy.cwsent.com> <201802172112.w1HLCI2k069334@pdx.rh.CN85.dnsmgr.net> From: Edward Napierala Date: Tue, 20 Feb 2018 14:17:01 +0000 X-Google-Sender-Auth: s1WMAdn-yLIScVbKs9a5mo0ZFBc Message-ID: Subject: Re: ps output line length change To: "Rodney W. Grimes" Cc: Cy Schubert , arch@freebsd.org, mike@karels.net, Ian Lepore Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2018 14:17:03 -0000 2018-02-17 21:12 GMT+00:00 Rodney W. Grimes < freebsd-rwg@pdx.rh.cn85.dnsmgr.net>: > > In message <1518882702.72050.204.camel@freebsd.org>, Ian Lepore writes: > > > On Fri, 2018-02-16 at 18:03 -0800, Cy Schubert wrote: > > > > In message <201802170046.w1H0kvxN032252@mail.karels.net>, Mike > Karels?? > > > > writes: > > > > > > > > > > [...] > > > > Agreed. I also agree scripts that expect wide output without ww are?? > > > > broken. However Linux ps, at least Red Hat, behaves the same. I > believe?? > > > > the change was made to be more Linux compatible and allow greater?? > > > > portability. > > > > > > > > > > > > > > > > > > > What do people think should be done? > > > > That's a tough one. Break Linux compatibility or break BSD?? > > > > compatibility? > > > > > > > > Generally Linux users use ps -ef which we don't support and columns > are?? > > > > different so, Linux compatibility is... well just isn't. > > > > > > > > My vote is to revert and have an environment variable with > defaults,?? > > > > e.g., PS=--linux or something similar. > > > > > > > > > > > > > > Linux compatibility is good and desirable, right up to the point where > > > it stomps on BSD compatibility. ??I think we should revert to historic > > > behavior. > > > > > > I'm agnostic about whether an env var is a good idea or not. ??I use > the > > > env vars for LESS and TOP and love the idea, but hate hate hate the > > > names (I've fought with conflicts on the too-common name TOP multiple > > > times over the years, most recently just last week my env var TOP > > > confused some makefile that had a TOP var in it). ??Could the var be > > > named something like PS_OPTS? > > > > Sure. I'm ok even if there is no Linux compatibility. If we choose an > > environment variable, I'm ok with any name as long as it makes sense. > > > > However Solaris had (I haven't used Solaris since Solaris 9) /usr/ucb > > for BSD compatible utilities. Should we consider something similar for > > linux compatibility? > > We already ahve the whole linuxlator thing, if they want a linux > ps cant they just.. um actually use a linux ps from /compat/linux? > I know ps grovels around in a lot of internals but this would, > imho, be the route to persue a "linux compatible" ps output. > Or install sysutils/coreutils and use the gls(1) - GNU version of ls(1), the same that's used with Linux - built as a native FreeBSD binary. From owner-freebsd-arch@freebsd.org Wed Feb 21 19:51:01 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D9D4CF24860 for ; Wed, 21 Feb 2018 19:51:01 +0000 (UTC) (envelope-from drosih@rpi.edu) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 73B996EDB2 for ; Wed, 21 Feb 2018 19:51:01 +0000 (UTC) (envelope-from drosih@rpi.edu) Received: by mailman.ysv.freebsd.org (Postfix) id 3841AF2485B; Wed, 21 Feb 2018 19:51:01 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 24617F24856 for ; Wed, 21 Feb 2018 19:51:01 +0000 (UTC) (envelope-from drosih@rpi.edu) Received: from smtp10.server.rpi.edu (gateway.canit.rpi.edu [128.113.2.230]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "canit.localdomain", Issuer "canit.localdomain" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C099D6EDAF for ; Wed, 21 Feb 2018 19:51:00 +0000 (UTC) (envelope-from drosih@rpi.edu) Received: from smtp-auth3.server.rpi.edu (smtp-auth3.server.rpi.edu [128.113.2.233]) by smtp10.server.rpi.edu (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id w1LJjvbH015229 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 21 Feb 2018 14:45:57 -0500 Received: from smtp-auth3.server.rpi.edu (localhost [127.0.0.1]) by smtp-auth3.server.rpi.edu (Postfix) with ESMTP id 1624058018; Wed, 21 Feb 2018 14:45:57 -0500 (EST) Received: from [172.16.67.1] (gilead-qc124.netel.rpi.edu [128.113.124.17]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: drosih) by smtp-auth3.server.rpi.edu (Postfix) with ESMTPSA id 0A6C958013; Wed, 21 Feb 2018 14:45:56 -0500 (EST) From: "Garance A Drosehn" To: "Mike Karels" Cc: arch@freebsd.org Subject: Re: ps output line length change Date: Wed, 21 Feb 2018 14:45:55 -0500 X-Mailer: MailMate (1.10r5443) Message-ID: <2280A28D-A54B-417B-B72D-38EE2F4EE521@rpi.edu> In-Reply-To: <201802170046.w1H0kvxN032252@mail.karels.net> References: <201802170046.w1H0kvxN032252@mail.karels.net> MIME-Version: 1.0 X-Virus-Scanned: ClamAV using ClamSMTP X-Bayes-Prob: 0.0001 (Score 0, tokens from: outgoing, @@RPTN) X-Spam-Score: 0.00 () [Hold at 10.10] X-CanIt-Incident-Id: 03VdvJVwf X-CanIt-Geo: ip=128.113.124.17; country=US; region=New York; city=Troy; latitude=42.7495; longitude=-73.5951; http://maps.google.com/maps?q=42.7495,-73.5951&z=6 X-CanItPRO-Stream: outgoing X-Canit-Stats-ID: Bayes signature not available X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.113.2.230 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 19:51:02 -0000 On 16 Feb 2018, at 19:46, Mike Karels wrote: > A couple of weeks ago, I sent email on the committers list proposing > reversion of r314685 changing the output line length for ps. In > particular, it uses unlimited line length if stdout is not a tty. > The previous code used the tty width if any of stdout, stderr, or > stdin was a tty. The change in r314685 has not been shipped in > any release yet. > > The responses to that email all agreed with reversion. However, > there has been some additional discussion in private email. > Therefore, I am sending this to arch@. I've lost track of how many times I've said this, but I'll say it one more: I think the change should be reverted. What the code currently does is fine, and is flexible enough. I've written many scripts which parse the output of 'ps', and the historical behavior has never hampered me. And I do write scripts which have to run on multiple unixes (in fact, most of my work is done on systems which are not running FreeBSD). -- Garance Alistair Drosehn = drosih@rpi.edu Senior Systems Programmer or gad@FreeBSD.org Rensselaer Polytechnic Institute; Troy, NY; USA From owner-freebsd-arch@freebsd.org Wed Feb 21 21:16:39 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 661C7F00EEE for ; Wed, 21 Feb 2018 21:16:39 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 06BFF739CF for ; Wed, 21 Feb 2018 21:16:39 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: by mailman.ysv.freebsd.org (Postfix) id B1CEAF00EED; Wed, 21 Feb 2018 21:16:38 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A05C6F00EEB for ; Wed, 21 Feb 2018 21:16:38 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: from smtp.vangyzen.net (hotblack.vangyzen.net [199.48.133.146]) by mx1.freebsd.org (Postfix) with ESMTP id 520BA739CE for ; Wed, 21 Feb 2018 21:16:37 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: from sweettea.beer.town (unknown [76.164.8.130]) by smtp.vangyzen.net (Postfix) with ESMTPSA id 3C4E95646B; Wed, 21 Feb 2018 15:16:31 -0600 (CST) Subject: Re: ps output line length change To: mike@karels.net, arch@freebsd.org References: <201802170046.w1H0kvxN032252@mail.karels.net> From: Eric van Gyzen Message-ID: <6fc846e5-5155-63f5-6931-ed83f5b86cbc@vangyzen.net> Date: Wed, 21 Feb 2018 15:16:30 -0600 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <201802170046.w1H0kvxN032252@mail.karels.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 21:16:39 -0000 On 02/16/2018 18:46, Mike Karels wrote: > A couple of weeks ago, I sent email on the committers list proposing > reversion of r314685 changing the output line length for ps. In > particular, it uses unlimited line length if stdout is not a tty. > The previous code used the tty width if any of stdout, stderr, or > stdin was a tty. The change in r314685 has not been shipped in > any release yet. > > The responses to that email all agreed with reversion. However, there > has been some additional discussion in private email. Therefore, I > am sending this to arch@. > > My reasoning is this; > > 1. The output line length for the following commands should reasonably > be the same in an interactive session: ps, ps | more, ps | grep. > > 2. The previous behavior is the way things have worked since 1990, > as Conrad pointed out. As others pointed out, it has long been known > that -ww was required to get unlimited lines, e.g. in a script. I > don't see any significant justification to change 28 years of precedent. > > 3. The rationale for the change included that it is easier for scripts > (which I maintain are broken if they assume this), and that it doesn't > matter if using less with left-right scrolling. We shouldn't make > assumptions about what the output is going through, let alone assume > left-right scrolling. The previous algorithm was described as magic, > but I think it is straightforward. Perhaps a comment is in order. > > I tried to think of a compromise solution, but the only thing that > comes to mind is messy: an environment variable that would enable > unlimited line length when the output was not a tty. That would not > be easier for scripts. And as Bruce noted, aliasing ps to "ps -ww" > does not work with old BSD-stype "ps axu". > > What do people think should be done? I agree that the change should be reverted. Eric From owner-freebsd-arch@freebsd.org Wed Feb 21 22:47:29 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 95D8FF07EEF for ; Wed, 21 Feb 2018 22:47:29 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 310DC775E2 for ; Wed, 21 Feb 2018 22:47:29 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: by mailman.ysv.freebsd.org (Postfix) id DB500F07EE6; Wed, 21 Feb 2018 22:47:28 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B402EF07EE5 for ; Wed, 21 Feb 2018 22:47:28 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 45E0E775E1 for ; Wed, 21 Feb 2018 22:47:27 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([96.50.22.10]) by shaw.ca with ESMTPA id odASeTgGUU5pnodATeDVM6; Wed, 21 Feb 2018 15:47:20 -0700 X-Authority-Analysis: v=2.3 cv=Tai4SyYh c=1 sm=1 tr=0 a=jvE2nwUzI0ECrNeyr98KWA==:117 a=jvE2nwUzI0ECrNeyr98KWA==:17 a=Op4juWPpsa0A:10 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=HZ-2u7k9vecDSnEffJ8A:9 a=iQ5819FEJirKHH-r:21 a=EB6xFrfuShcN0tnh:21 a=CjuIK1q_8ugA:10 a=4CuRDvcBKcFxYpiQTpsA:9 a=l227UVPgiwdiHz01:21 a=OQJIPcPUHl2ddLWS:21 a=u8IPemfICKrfH9PA:21 a=_W_S_7VecoQA:10 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 Received: from [25.80.3.80] (unknown [24.114.39.120]) by spqr.komquats.com (Postfix) with ESMTPSA id E0E5410D7; Wed, 21 Feb 2018 14:47:15 -0800 (PST) MIME-Version: 1.0 From: Cy Schubert Subject: RE: ps output line length change Date: Wed, 21 Feb 2018 14:47:15 -0800 To: Garance A Drosehn , Mike Karels CC: "arch@freebsd.org" Message-Id: <20180221224715.E0E5410D7@spqr.komquats.com> X-CMAE-Envelope: MS4wfFvbw5G7/ineU/bWus0duG1ypcp3fCGGRwMVFiAMxxFL6t50wzOMkzozR7Ru8oFv+oHFyDr9aRXFnV99/MebrRQhCrdcveq1LsOBwH+PneCcT51pp42c caUIBKeWORov6iPL6v1QxB3qA7exrEr9WD4BhSyD0oV/SZXoRSb1wmZxIEGdWBFCAvQVtwk9PMWlqKpwsux4sXSDBmnP27B00JSWaJ137WhGIzU5WS9xL23f Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 22:47:29 -0000 Iirc cem@ committed the original patch. Maybe someone should ask him to rev= ert. --- Sent using a tiny phone keyboard. Apologies for any typos and autocorrect. Also, this old phone only supports top post. Apologies. Cy Schubert or The need of the many outweighs the greed of the few. --- -----Original Message----- From: Garance A Drosehn Sent: 21/02/2018 11:52 To: Mike Karels Cc: arch@freebsd.org Subject: Re: ps output line length change On 16 Feb 2018, at 19:46, Mike Karels wrote: > A couple of weeks ago, I sent email on the committers list proposing > reversion of r314685 changing the output line length for ps. In > particular, it uses unlimited line length if stdout is not a tty. > The previous code used the tty width if any of stdout, stderr, or > stdin was a tty. The change in r314685 has not been shipped in > any release yet. > > The responses to that email all agreed with reversion. However, > there has been some additional discussion in private email. > Therefore, I am sending this to arch@. I've lost track of how many times I've said this, but I'll say it one more: I think the change should be reverted. What the code currently does is fine, and is flexible enough. I've written many scripts which parse the output of 'ps', and the historical behavior has never hampered me. And I do write scripts which have to run on multiple unixes (in fact, most of my work is done on systems which are not running FreeBSD). --=20 Garance Alistair Drosehn =3D drosih@rpi.edu Senior Systems Programmer or gad@FreeBSD.org Rensselaer Polytechnic Institute; Troy, NY; USA _______________________________________________ freebsd-arch@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-arch To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" From owner-freebsd-arch@freebsd.org Thu Feb 22 01:16:29 2018 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3A5EBF1462C; Thu, 22 Feb 2018 01:16:29 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D633A7E3DE; Thu, 22 Feb 2018 01:16:28 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (ralph.baldwin.cx [66.234.199.215]) by mail.baldwin.cx (Postfix) with ESMTPSA id F25EB10A8C2; Wed, 21 Feb 2018 20:16:27 -0500 (EST) From: John Baldwin To: freebsd-arch@freebsd.org Cc: Cy Schubert , Garance A Drosehn , Mike Karels , "arch@freebsd.org" Subject: Re: ps output line length change Date: Wed, 21 Feb 2018 16:59:24 -0800 Message-ID: <3369243.YQvd3VYPi2@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.1-STABLE; KDE/4.14.30; amd64; ; ) In-Reply-To: <20180221224715.E0E5410D7@spqr.komquats.com> References: <20180221224715.E0E5410D7@spqr.komquats.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Wed, 21 Feb 2018 20:16:28 -0500 (EST) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2018 01:16:29 -0000 On Wednesday, February 21, 2018 02:47:15 PM Cy Schubert wrote: > Iirc cem@ committed the original patch. Maybe someone should ask him to revert. Mike has. This thread is to determine what the consensus is. My preference is for the old behavior. > --- > Sent using a tiny phone keyboard. > Apologies for any typos and autocorrect. > Also, this old phone only supports top post. Apologies. > > Cy Schubert > or > The need of the many outweighs the greed of the few. > --- > > -----Original Message----- > From: Garance A Drosehn > Sent: 21/02/2018 11:52 > To: Mike Karels > Cc: arch@freebsd.org > Subject: Re: ps output line length change > > On 16 Feb 2018, at 19:46, Mike Karels wrote: > > > A couple of weeks ago, I sent email on the committers list proposing > > reversion of r314685 changing the output line length for ps. In > > particular, it uses unlimited line length if stdout is not a tty. > > The previous code used the tty width if any of stdout, stderr, or > > stdin was a tty. The change in r314685 has not been shipped in > > any release yet. > > > > The responses to that email all agreed with reversion. However, > > there has been some additional discussion in private email. > > Therefore, I am sending this to arch@. > > I've lost track of how many times I've said this, but I'll say it > one more: I think the change should be reverted. What the code > currently does is fine, and is flexible enough. I've written > many scripts which parse the output of 'ps', and the historical > behavior has never hampered me. And I do write scripts which > have to run on multiple unixes (in fact, most of my work is done > on systems which are not running FreeBSD). > > -- John Baldwin