libproc-rs for ravynos

[andrewdavidmackenzie]

Saw a post on your OS and asked myself how I could help...

With not that much time and wanting to focus more on rust, my only thought was to help make sure that the libproc-rs (rust bindings for libproc on darwin) that I maintain works well on RavynOS.

If you think that makes sense, then just suggest to me here how I could possibly test it out, or add it to the OSs supported by libproc-rs, and the CI matrix

[mszoek]

Hey, thanks! That is awesome. We do have a libproc from FreeBSD, but it is not the same as the Darwin one. They have different functions. That said, I think we will probably need the functions from the Darwin libproc AND the functions from the current FreeBSD one. I doubt the Darwin code will work with our kernel, so the best course might be to add implementations of those functions to our current library. And then your Rust binding should Just Work (tm), and we can talk more about adding to the test matrix!

I'll create an issue for the libproc enhancements.

[mszoek]

Actually I guess we can just use this issue for the enhancements :)

[andrewdavidmackenzie]

Cool. Want a list of the functions used by libproc-rs, or you would just go for a full replication of what is available in Darwin? Let me know if I can help in the meantime.

[mszoek]

We probably have to do the full impl, but please send me a list so I can prioritize those ones!

[andrewdavidmackenzie]

The bindings were done manually before, but now bindgen is used, so that generated bindings for everything in libproc.h, so it will need the structs and functions defined for bindgen to work. I think it uses pkg-config to find the header files?

• That's maybe something to keep in mind for the build (part from working rustc etc, will need bindgen...
• BTW: errno is used to convey errors in many cases, although I don't use specific codes
• It makes it harder to know what functions are actually used ahead of time (without trying the build)

I have reviewed my code vs. the docs, and it looks up to date, so these are the rust methods implemented:

pub fn listpids(proc_types: ProcType) -> Result<Vec<u32>, String> (macos) (linux)
pub fn listpidspath(proc_types: ProcType, path: &str) -> Result<Vec<u32>, String> (macos) (linux)
pub fn pidinfo<T: PIDInfo>(pid : i32, arg: u64) -> Result<T, String> (macos)
pub fn regionfilename(pid: i32, address: u64) -> Result<String, String> (macos)
pub fn pidpath(pid : i32) -> Result<String, String> (macos) (linux)
pub fn libversion() -> Result<(i32, i32), String> (macos)
pub fn name(pid: i32) -> Result<String, String> (linux) (macos)
pub fn listpidinfo<T: ListPIDInfo>(pid : i32, max_len: usize) -> Result<Vec<T::Item>, String> (macos)
pub fn pidcwd(pid: pid_t) -> Result<PathBuf, String> (linux)
pub fn cwdself() -> Result<PathBuf, String> (linux)
pub fn pidfdinfo<T: PIDFDInfo>(pid : i32, fd: i32) -> Result<T, String> (macos)
pub fn pidrusage<T: PIDRUsage>(pid : i32) -> Result<T, String> (macos)
pub fn kmsgbuf() -> Result<String, String>

and it I unfolded to this list of libproc functions called:

• proc_regionfilename
• proc_pidpath
• proc_pidinfo
• proc_listpids
• proc_pidfdinfo
• proc_pid_rusage
• proc_kmsgbuf
• proc_libversion (doubt this is used by anyone)
• proc_name