Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 20 May 2014 12:22:01 -0700
From:      Adrian Chadd <adrian@freebsd.org>
To:        Zaro Korchev <zkorchev@mail.bg>
Cc:        "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org>
Subject:   Re: [GSoC] Machine readable output from userland utilities
Message-ID:  <CAJ-Vmokbpq4huDtT1a6oZiNn-8BOYK1W0MaQ_hV7Mb7-84ug%2BQ@mail.gmail.com>
In-Reply-To: <49E9736E-AD14-4647-8B15-30603D01360C@mail.bg>
References:  <49E9736E-AD14-4647-8B15-30603D01360C@mail.bg>

next in thread | previous in thread | raw e-mail | index | archive | help
Hi!

So I imported libstatfoo from Sam Leffler into base, specifically for
this kind of purpose. What I'd like to do is extend this and
incorporate it into existing tools like vmstat, iostat and such. That
way we can then just teach libstatfoo about XML, or JSON - and then
the tools all inherit it.


-a


On 20 May 2014 09:59, Zaro Korchev <zkorchev@mail.bg> wrote:
> I'm working on the project "Machine readable output from userland utiliti=
es" and I want to share my ideas and thoughts.
>
> Here is the wiki page of the project:
> https://wiki.freebsd.org/SummerOfCode2014/MachineReadableFromUserlandUtil=
s
>
> I'm planning to create a unified output abstraction in the form of a libr=
ary. The tools supporting the machine-readable output feature will write ou=
tput exclusively using the library. The exact output format will be customi=
zable. Several backend libraries (like libucl and libnv) can be used to imp=
lement different formats.
> Such library can either be compiled statically into each application or l=
inked dynamically (depending on space/performance/versioning and other cons=
iderations).
> Each tool will have to be modified to support the new output mechanism. T=
hese modifications could trivially be turned on and off using a macro switc=
h.
> One issue that must be considered is how to manage long outputs since it =
may not be possible to store all data in memory. This would happen rarely b=
ut can still be a problem. Probably the easiest way to solve this is to add=
 streamed dumping capability into the underlying libraries.
>
> Do you have any suggestions or ideas?
>
>
> Thank you,
> Zaro
> _______________________________________________
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org=
"



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmokbpq4huDtT1a6oZiNn-8BOYK1W0MaQ_hV7Mb7-84ug%2BQ>