Statsfs: A Proposed Linux File-System For Kernel Statistics

[cjcox]

The Unix philosophy is everything is a file.

The Linux philosophy is everything is in systemd.

[Larry$ilverstein]

If you don't mind only supporting "the largest subset of JSON that can be unpacked into static C structures, without using malloc(3)" ...

Not using malloc() at all is mostly cargo-culting. Using malloc() judiciously to pre-allocate stuff at early startup is no more likely to cause problems than having a huge .bss section (which the loader still has to allocate anyway).

you could use ESR's ...

Stopped reading there.

[ssokolow]

JSON introduces minor overhead compared to ad-hoc space/tab separated values. In addition I'm not sure if POSIX includes any JSON parsers. Most JSON parsers require tons of dependencies, e.g. 100 Maven/Cargo/NPM packages and/or 100 MB language runtimes.

If you don't mind only supporting "the largest subset of JSON that can be unpacked into static C structures, without using malloc(3)", you could use ESR's microjson. It's under 2-clause BSD, the .c and .h file together are only 27.82KiB and it's "extremely well-tested code. This is essentially the same parser used in GPSD and its client libraries, which have hundreds of millions of deployments underneath Google Maps in Android phones."

[caligula]

Okay can those text streams be json please ?

JSON introduces minor overhead compared to ad-hoc space/tab separated values. In addition I'm not sure if POSIX includes any JSON parsers. Most JSON parsers require tons of dependencies, e.g. 100 Maven/Cargo/NPM packages and/or 100 MB language runtimes.

[S.Pam]

Json is horrible, so no please.
However if you must, perhaps implement a parser? cat /sys/kernel/stats/somestat | stat2json | do something

Edit: maybe you could load a module that provides additional files of somestats as somestats.json, somestats.xml, aso.

[sarfarazahmad]

I agree, but someone will tell you this is against Unix philosophy ("Write programs to handle text streams, because that is a universal interface.")

Okay can those text streams be json please ?

[k1e0x]

Well.. One of the problems with /proc is you are essentially parsing machine data, into human readable data, and then back into machine data for programs.

The human layer causes problems too, so it's not always optimal to have that.

The question becomes more "what are you actually trying to do, and what is the best way to do that?" - Do you *really* want to get all your machine statistics with cat? really? (or scanf() )

I don't think up-stack that is going to look really slick.. but.. whatever.

[Etherman]

We need a c api, not another thing text thing that everyone will write parsing functions for over and over.

That's what libraries are for.

[NotMine999]

When I think about text interface via a pseudo-filesystem or via a C API... I think the text interface will be easier.

As kernel elements in future releases expose more and more stats, then it's a matter of updating some kernel code to expose it via the pseudo-filesystem that resides IN RAM. That seems easily extensible. When I look at HWMON data in SysFS it is easy to access & manipulate via CLI, and if stored data is moved around within SysFS it's just a matter of learning where it was moved to and updating my own text-based scripts.

With a C API the only thing being exposed is the API, not the data. Now a userspace binary program, and the API opens the door to all sorts of userspace binary programs (how many variants will we see?), has to be updated to poke the right variables into the API to get an answer from Linux via the API. If the wrong variables are poked into the API call, then the API will expose either wrong data or no data; you can replicate that concept easily in your own programming. Why does a userspace binary program have to poke the right bits into the API call? Well, you don't expect the actual user to have to know that stuff, right? Next, if there is returned data from the API call, it has to be parsed and displayed on what... the CLI or do you want a GUI with that userspace binary program?

For me the use of a C API seems like way too many moving parts for something that should be oh so simple.

[k1e0x]

We need a c api, not another thing text thing that everyone will write parsing functions for over and over.

Agree. Linux has too many pseudo filesystems. It also may break compatibility with other Unix'es.