From owner-freebsd-current@FreeBSD.ORG Wed Mar 4 19:55:49 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 760DDFC7 for ; Wed, 4 Mar 2015 19:55:49 +0000 (UTC) Received: from mail-la0-f49.google.com (mail-la0-f49.google.com [209.85.215.49]) (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 EC428903 for ; Wed, 4 Mar 2015 19:55:48 +0000 (UTC) Received: by labgf13 with SMTP id gf13so22365584lab.10 for ; Wed, 04 Mar 2015 11:55:40 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=qJCOWzK7PvSxFKH+O+I44NVa0MzQqrImGbxhBlW6EbA=; b=g7cB0HW5mAt7ZO7m6MegtyyeSLKiG+umLEPynN/AU0BMoyiqZHIZCN3a3CKdk5cfxt WoJ+Ac6m80UqZIAGok+a4Uy/HE9M4znCJ8yUBeMEQxGqDl8VtjgBycCR3HfNhdUPK5Lb j4JFMNQus+BctcP7oGcpGa/Q+siHT71rCpePGngLRkLIPrzwHkZ5L4Sf8ViEnQeyv6Sr NlheeUr2xhshdTGcjQjHxyT3VNtMiQ1X8O9zVhhjyX2jVDpXqGyUEeab1EqBsv/kYE1i A67IM81f0RAB7i7aIwQFdPvA4cOz2FZ+dSibjnBoDnVZQJwHHG6w13bGIeG7kG5qsXnd MU3w== X-Gm-Message-State: ALoCoQnUCkvsiiTOi6ON5fSQQq3a9KgrmyIfHfbbolMDZ8QfRZIER+btsqqqkCDrN1Olp7JFF17h X-Received: by 10.152.6.34 with SMTP id x2mr475551lax.47.1425498940715; Wed, 04 Mar 2015 11:55:40 -0800 (PST) Received: from [192.168.1.2] ([89.169.173.68]) by mx.google.com with ESMTPSA id w9sm926166laj.24.2015.03.04.11.55.39 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Mar 2015 11:55:39 -0800 (PST) Message-ID: <54F7633B.3070909@freebsd.org> Date: Wed, 04 Mar 2015 22:55:39 +0300 From: Andrey Chernov User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: John Baldwin , freebsd-current@freebsd.org Subject: Re: Massive libxo-zation that breaks everything References: <54F31510.7050607@hot.ee> <54F50F15.4050300@freebsd.org> <15905806.StXgP74c8j@ralph.baldwin.cx> In-Reply-To: <15905806.StXgP74c8j@ralph.baldwin.cx> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit 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 19:55:49 -0000 On 04.03.2015 19:21, John Baldwin wrote: > 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.) > I agree that adding machine-readable output + separate option on a per-tool basis, when it is really needed, is more clean approach which don't break Unix way of things. In such case we don't intermix structured representation with human readable, so the chances that a bug in one representation code flow will affect other one are minimal unlike in unified libxo approach, which already demonstrate this weakness. -- http://ache.vniz.net/