Date: Wed, 04 Mar 2015 16:11:09 -0500 From: John Baldwin <jhb@freebsd.org> To: Alfred Perlstein <bright@mu.org> Cc: freebsd-current@freebsd.org, David Chisnall <theraven@freebsd.org>, Allan Jude <allanjude@freebsd.org> Subject: Re: Massive libxo-zation that breaks everything Message-ID: <2442911.VSALjZ0gTW@ralph.baldwin.cx> In-Reply-To: <54F75076.8060102@mu.org> References: <54F31510.7050607@hot.ee> <15905806.StXgP74c8j@ralph.baldwin.cx> <54F75076.8060102@mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2442911.VSALjZ0gTW>