On Wed, Mar 4, 2015 at 1:11 PM, John Baldwin <j...@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
> > > fields in capabilities that we don't currently bother printing (and
> > > I don't think the human-readable output should print due to it being
> > > 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
> 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
> Put another way, in my mind something like pciconf -l is a presentation
> and it's just one way of representing the data involved. Ideally,
> like pciconf -l could be rewritten as a consumer of the raw,
> data (I'm not sure I would rewrite it, but in theory the data flow should
> 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
> 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
> could implement multiple "views" of the data (think lspci -t vs pciconf
> However, I think that requires designing the schema in terms of the data
> are describing, not based on one extant view/presentation. To expend this
> further, suppose that pciconf supported multiple views like lspci, would
> 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
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
email@example.com mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"