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

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
freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to