Re: Massive libxo-zation that breaks everything

On Wed, Mar 4, 2015 at 1:11 PM, John Baldwin <jhb_at_freebsd.org> 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