From owner-freebsd-current@FreeBSD.ORG Wed Mar 4 21:11:28 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 02CF9287; Wed, 4 Mar 2015 21:11:28 +0000 (UTC) Received: from bigwig.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 CE1EC12B; Wed, 4 Mar 2015 21:11:27 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-54-116-245.nwrknj.fios.verizon.net [173.54.116.245]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 3CAF8B913; Wed, 4 Mar 2015 16:11:26 -0500 (EST) From: John Baldwin To: Alfred Perlstein Subject: Re: Massive libxo-zation that breaks everything Date: Wed, 04 Mar 2015 16:11:09 -0500 Message-ID: <2442911.VSALjZ0gTW@ralph.baldwin.cx> User-Agent: KMail/4.14.2 (FreeBSD/10.1-STABLE; KDE/4.14.2; amd64; ; ) In-Reply-To: <54F75076.8060102@mu.org> References: <54F31510.7050607@hot.ee> <15905806.StXgP74c8j@ralph.baldwin.cx> <54F75076.8060102@mu.org> 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.2.7 (bigwig.baldwin.cx); Wed, 04 Mar 2015 16:11:26 -0500 (EST) Cc: freebsd-current@freebsd.org, David Chisnall , Allan Jude X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 21:11:28 -0000 On Wednesday, March 04, 2015 10:35:34 AM Alfred Perlstein wrote: > On 3/4/15 8:21 AM, John Baldwin wrote: > > I would probably want > > pciconf -l in that case to dump the entire PCI header (right now the > > human-readable pciconf -l only dumps a subset), and I would want it to dump > > fields in capabilities that we don't currently bother printing (and that > > I don't think the human-readable output should print due to it being too > > obscure, etc.) > > I actually agree on this and this is why I was upset that the more > straightforward GSoC code was shot down in favor of this. That said > don't we all need to look at the greater good when making software and > we have some consensus on this so its worth going forward imo. > > We can agree on something even though it might make hairs stand up or we > just stagnate. I think there might some cases where converting the existing output directly is fine (netstat -s comes to mind), but I think we should not be opposed to the idea that some utilities should output a different set of data for machine -readable. Put another way, in my mind something like pciconf -l is a presentation layer, and it's just one way of representing the data involved. Ideally, something like pciconf -l could be rewritten as a consumer of the raw, machine-readable data (I'm not sure I would rewrite it, but in theory the data flow should be something like "raw data in kernel" -> "machine-readable format" -> "presentation".) For example, pciconf -l currently has the misfeature that it is a flat listing and doesn't properly communicate the hierarchy that you can see in devinfo (and often times that hiearchy does matter). I would want a machine-readable schema for PCI devices to describe the hierarcy so that you could implement multiple "views" of the data (think lspci -t vs pciconf -l). However, I think that requires designing the schema in terms of the data you are describing, not based on one extant view/presentation. To expend this further, suppose that pciconf supported multiple views like lspci, would you want that to translate into multiple machine-readable schemas? -- John Baldwin