Date: Tue, 3 Mar 2015 09:09:43 +0000 From: David Chisnall <theraven@FreeBSD.org> To: Andrey Chernov <ache@FreeBSD.org> Cc: freebsd-current@freebsd.org, Allan Jude <allanjude@freebsd.org> Subject: Re: Massive libxo-zation that breaks everything Message-ID: <B38C4D7E-05DC-4D35-A650-37A466FF9508@FreeBSD.org> In-Reply-To: <54F50F15.4050300@freebsd.org> References: <54F31510.7050607@hot.ee> <54F34B6E.2040809@astrodoggroup.com> <CAG=rPVfcB1Fy_8mHq-t5Ay07yrzuSGthQ0ZcGzvp0XG9gSSzkg@mail.gmail.com> <54F35F29.4000603@astrodoggroup.com> <54F429EF.5050400@freebsd.org> <54F46536.8040607@mu.org> <54F4C03F.7030704@freebsd.org> <54F4FECB.90501@freebsd.org> <54F504EF.3030303@freebsd.org> <54F50F15.4050300@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 3 Mar 2015, at 01:32, Andrey Chernov <ache@FreeBSD.org> wrote: >=20 > So, why you ever need to modify wc? Just load wc inside your > json/xml/etc writer, replacing its printf at the ld-elf.so level. You can't get structured output from printf() because printf() takes = unstructured input. It's a string with some variables pasted in, but no = awareness of context. The libxo changes to the tools are simply marking the output as having a = defined structure. The library then translates this abstract structure = into something that can be parsed easily by external tools. If your argument is that the UNIX philosophy is simple tools doing one = thing well, then please remember the context of this philosophy: It = dates back to the original UNIX systems *that did not support shared = libraries* and was an argument used to justify not implementing them. = This is why globbing is in the shell instead of a shared library and why = some variant of mv *.a *.b works on every command-line interface except = for a UNIX shell. Even with that in mind, small changes to individual tools are a *lot* = simpler than one massive monolithic tool that understands the output = formats of every other tool in the base system and can transform them. = Why do you think a few library calls in each application is more complex = *than an entire parser per tool*? I am reminded of the time about ten years ago when I was writing a = system info widget for a DE. Getting the total amount of RAM, number of = cores, and CPU speed on FreeBSD, OpenBSD, NetBSD, and Solaris proved to = be a single sysctl for each attribute. On Linux, the information was = all there, in /proc/cpuinfo, so I had to write a parser. Unfortunately, = the format changed across kernel revisions and across architectures. In = the end, I had to link in a 300KB library to parse information that the = kernel already had in a machine-readable format and present it to me in = a machine-readable format. Hopefully there's a lesson here that we can learn from: human-readable = formats do not make good intermediate representations when communicating = between tools. If your argument is about maintainability of these changes, then please = point to concrete instances where the changes are complex and difficult = to maintain. If your argument is about binary size, then it would be relatively easy = for us to add a version of libxo for static linking into the versions in = /rescue that only supported plain-text output, but again, please = quantify your objections: What is the size increase that you're seeing = and what kind of devices is this causing a problem for? The general approach of making tools produce machine-readable output has = been under discussion for *years* and the integration of libxo has been = underway for several months, prior to which it was used inside Juniper. = If you had a better approach, then the correct time to raise it was back = when the requirement to produce machine-readable output was raised. The = subject of this thread is just plain trolling (is everything broken by = libxo? No. Is anything broken by libxo? Occasionally, but new = features often come with temporary breakage that's found and fixed in = testing: that's why we have -CURRENT). David
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B38C4D7E-05DC-4D35-A650-37A466FF9508>