port / wrap / package psutil for rust

[graydon]

https://code.google.com/p/psutil/ is a very tidy collection of generic operating system and process monitoring interfaces, with supporting C code for all our tier-1 platforms. I would very much like to see this ported or exposed-and-wrapped in std::os.

[emberian]

I can take this on. psutil is a nice library but deeply integrated with python. I think it'd be worth separating the important platform bits into their own library which is wrapped by rust.

[emberian]

So psutil is entirely unsuitable as a library. It is deeply tied into Python and only exports Python data structures. Its organization is unideal for direct adaptation to standalone usage.

But there is libstatgrab which is a much better option. It is, however, LGPL. I've contacted the authors to see if it could be relicensed or an exception made.

[graydon]

I meant the platform specific parts for reading the info, not the parts that form python values.

[emberian]

The platform specific parts only feed into python values, there's no separation or cross-platform non-python data structures or anything

[emberian]

Status: investigated libstatgrab as an alternative, but it is LGPL which is unsuitable for inclusion into the standard library. Seems there are no other good libraries, so writing one would be necessary. I'll get to it... eventually, probably after rustdoc, but if someone else wants to do it before that's fine.

It'd be best to write a liberally-licensed, robust cross-platform C library that does this, to benefit everyone, and write a Rust wrapper on top.

[catamorphism]

(bug triage) Still would be nice, not a milestone blocker.

[nibrahim]

I'd like to give this a shot. It seems like something small enough for me to work on as well as to contribute something useful. My plan is to first write a little non copyleft C library that does the same work as the one in psutil but without the Python bindings. I'll make it work fine as a C library. After that, I'll write a rust wrapper for this. I do my work on Debian so I'll make the Linux version first as a proof of concept and work from there.

Does this sound like a proper plan?

[emberian]

@nibrahim that'd be great!

[nibrahim]

Well, I'll give it a shot. Gotta start somewhere. :)

[nibrahim]

I got tied up but have made some small progress in writing the C parts. If someone has the time to look and offer comments, I'd value them. My C is far from production quality - https://github.com/nibrahim/cpslib

[nham]

Triage bump.

[brson]

I think this is not suitable for in-tree. Somebody should build this in Cargo.

[nibrahim]

Can you elaborate a little? What do you mean by build this in cargo?