From owner-freebsd-current@FreeBSD.ORG Wed Mar 4 23:03:35 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 278E3A74; Wed, 4 Mar 2015 23:03:35 +0000 (UTC) Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::22d]) (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 D22E0FB0; Wed, 4 Mar 2015 23:03:34 +0000 (UTC) Received: by ykbq9 with SMTP id q9so6272267ykb.13; Wed, 04 Mar 2015 15:03:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QY2eVmAnd7WcVTJ2cc7UoZVzwJVa7OsIFRozBEHgiFQ=; b=HGTMkl6+5F3L/ajUInOxS3PR06Sbh/MvVHizX943Kn9KQPE3MIHwXuGkifav61/ygB iGFk1N4gtIPOgoFaBtEKOSAejEQyMWU/8qtmmUFYykmtpydWl8FP8gWdOiHY6XrZa2My K+ROMZUxEVCDNv6ULBqFRw9jE4PZ7PJngPMw4OgNWFTgpKQ7SelAD8pAxqhSauo+NFMX hZJrDJgomOOuf/6lLw5V/Tell1a5h0Phi7tlJh4MWG74fNsixjGKCdQBYkNF0JoEEniM udo6H98ARhQ2e0PSyrI1d6kUc6gJYHVub8rKQcQJeidbdQzL27a8xmH1ISVnpfXw+kpU JO8g== MIME-Version: 1.0 X-Received: by 10.170.203.198 with SMTP id u189mr4968319yke.107.1425510213962; Wed, 04 Mar 2015 15:03:33 -0800 (PST) Received: by 10.170.60.85 with HTTP; Wed, 4 Mar 2015 15:03:33 -0800 (PST) In-Reply-To: <2442911.VSALjZ0gTW@ralph.baldwin.cx> References: <54F31510.7050607@hot.ee> <15905806.StXgP74c8j@ralph.baldwin.cx> <54F75076.8060102@mu.org> <2442911.VSALjZ0gTW@ralph.baldwin.cx> Date: Wed, 4 Mar 2015 15:03:33 -0800 Message-ID: Subject: Re: Massive libxo-zation that breaks everything From: Mehmet Erol Sanliturk To: John Baldwin Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Alfred Perlstein , David Chisnall , Allan Jude , freebsd-current 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 23:03:35 -0000 On Wed, Mar 4, 2015 at 1:11 PM, John Baldwin wrote: > 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 > _______________________________________________ > > If I were the sole designer of the XML ( or any other such as JSON , YAML , etc. ) output system I would do the following : If a value is generated , and should be stored to output file as soon as possible ( such as debugging needs ) , the present sample in the Phabricator review is suitable . For other cases , I would define a record to store the variable values to list later , for example , pci_XML . Within related program part , by trying as much as to write assignment statements near to each other , I would assign values to the pci_XML variables . At the end of assigning values , I would call a routine to store the pci_XML record to file ( create file , write values from pci_XML record , close file ) . Within that routine , it is possible to store the values of pci_XML record in any way , without making difficult to read primary related program . Updates to that routine will not affect the calling program parts much . As a companion to writing routine , I would develop a reading routine ( open file , read values into pci_XML , close the file ) to call from where processing of the output file is required . As a third routine to display values by using pci_XML to the user during interactive work . Thank you very much . Mehmet Erol Sanliturk