Date: Wed, 4 Mar 2015 15:03:33 -0800 From: Mehmet Erol Sanliturk <m.e.sanliturk@gmail.com> To: John Baldwin <jhb@freebsd.org> Cc: Alfred Perlstein <bright@mu.org>, David Chisnall <theraven@freebsd.org>, Allan Jude <allanjude@freebsd.org>, freebsd-current <freebsd-current@freebsd.org> Subject: Re: Massive libxo-zation that breaks everything Message-ID: <CAOgwaMsWk4YbRDAOxL%2BJDQDDtU3Hph9YMGRC5ZZw93qh0X=nNA@mail.gmail.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Mar 4, 2015 at 1:11 PM, John Baldwin <jhb@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOgwaMsWk4YbRDAOxL%2BJDQDDtU3Hph9YMGRC5ZZw93qh0X=nNA>