tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: wc(1) Output and POSIX

On 28.12.2016 04:14, David Holland wrote:
> On Wed, Dec 28, 2016 at 02:54:00AM +0000, David Holland wrote:
>  > I... think the library itself looks pretty gross,
> to wit, it's doing almost exactly the same things as proplib or any of
> the proposed proplib replacements, just with a very slightly different
> goal.

The libxo library as it's done in FreeBSD is an improvement for my
use-case, however it's not ideal. I mean, outputing from system/native
tools stream in the standarized format like json/xml/yaml/etc.

I want to serialize the state of a running system and to achieve this I
need to serialize all system tools from *bin, that are not trivial
filesystem accessors (I would treat wc(1) as a program in this group -
but if there is a use-case to render such property of a file, why not);
and render everything into unified format and with a tool like osquery
from Facebook.

   Performant Endpoint Visibility

   osquery allows you to easily ask questions about your Linux,
   Windows, and OS X infrastructure. Whether your goal is intrusion
   detection, infrastructure reliability, or compliance, osquery gives
   you the ability to empower and inform a broad set of organizations
   within your company.


My goal is to make frontend with Lua (meta)tables and (lib)SQL (reuse
sqlite?), while translating it to osquery should be straight-forward.

I know a potential user interested to use graphql & json for the same
task to introspect system and orchestrate system utilities like debuggers.


I faced a problem that to achieve this task I would need to reinvent
tools like ifconfig(8) or mixerctl(1) and base each conceptual set of
tables (like for network interfaces) on the ioctl(2) layer or write a
parser of stdout for every tool... and maintain it.

Another option would be to go for libxo/libprop or refactor our tools
into libraries and wrappers - like libifconfig(3) + ifconfig(8). A
library and wrapper could use libprop(3) to communicate one the other,
and reusing the library by third party tools would be a matter of
linking and adding a thin layer to generate appropriate format from
serialized Property List. For users requesting JSON or other format
offered by libxo.. just link libifconfig and generate what's wanted.

As a research, one step forwards is to get libsystem, and another step
is to serialize the full-state of system into single file (e.g. Lua
state). It's in contrast to the Linux world, as that it's not about
reinventing existing tools and mechanisms (like new run level concepts),
absorbing them into single library; but the goal is to add accessors to
orchestrate already well defined interfaces with a unified format and
with unified tool to introspect the system.

The goal of my use-case is to generate GUI plugins for system
interfaces, e.g. bozohttpd plugins in Lua or administrator panel in a
desktop window manager. As far as I know, the goal of libxo was to
reduce the cost & effort of creating similar tools.

I'm not convinced about libxo as:
 - It introduces complexity in *bin utilities,
 - The same task is achievable with already existing libprop(3),
 - There is need to redefine stdout/stderr functions that have regular
idioms like to replace err(3) with libxo alternative,
 - I would like to bypass the need for execve(2) (effectively going to
uniprogram-like solution),
 - I don't need wrapper for lib* when I want to use introspection layer,
 - I have number of use-cases to link programs like (lib)ifconfig(8)
with C code, while going to the ioctl(2) level or pipe stream and
parsing output (even with xml) is heavy.

Attachment: signature.asc
Description: OpenPGP digital signature

Home | Main Index | Thread Index | Old Index