From owner-freebsd-current@FreeBSD.ORG Wed Mar 4 16:23:26 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 C012B2BE; Wed, 4 Mar 2015 16:23:26 +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 96749BBB; Wed, 4 Mar 2015 16:23:26 +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 EDABAB91F; Wed, 4 Mar 2015 11:23:24 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Subject: Re: Massive libxo-zation that breaks everything Date: Wed, 04 Mar 2015 11:21:27 -0500 Message-ID: <15905806.StXgP74c8j@ralph.baldwin.cx> User-Agent: KMail/4.14.2 (FreeBSD/10.1-STABLE; KDE/4.14.2; amd64; ; ) In-Reply-To: References: <54F31510.7050607@hot.ee> <54F50F15.4050300@freebsd.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 11:23:25 -0500 (EST) Cc: 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 16:23:26 -0000 On Tuesday, March 03, 2015 09:09:43 AM David Chisnall wrote: > Hopefully there's a lesson here that we can learn from: human-readable > formats do not make good intermediate representations when communicating > between tools. I think this is actually an argument against libxo-ification in the one case where I've cringed a bit at the diffs: pciconf. The current pciconf code is tailored to outputting something human readable. For non-human output I would probably generate different output (not just put tags on the human output) because I would want the non-human output to be both more verbose and more raw. I think some other cases like 'netstat -s' are far more straightforward as the current output maps fairly well to the backing structure, but in general I would want machine-readable output that is closer to the structures than to the human-readable formatting of them. For example, for something like 'mfiutil show drives', I would want the human readable format to stay as it is (it only highlights certain fields in the PD structures) but I would want the machine-readable format to basically output tagged versions of the backing structures from sys/dev/mfi/mfireg.h. That way the machine-readable format has all of the data instead of only the subset that is presented in the human-readable output. So while I am in general a big fan of having machine-readable output from tools (and I think it belongs in the base system, and I don't think you want a post-processing tool), I think there is a bit of a flawed assumption that says that I want the same data in the human-readable format that I want in the machine-readable format. I, for one, don't. I want the human-readable form more condensed. > If your argument is about maintainability of these changes, then please > point to concrete instances where the changes are complex and difficult to > maintain. When I've looked at the xo diffs for pciconf, my reaction has been "ugh, I guess I'm not going to work on pciconf again in the future because that's super ugly". I don't object to the idea, I think I would just rather have a very different schema for machine-readable output. 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.) -- John Baldwin