OpenBSD support

[landryb]

Related to #429, i'm working on a basic OpenBSD support in https://github.com/landryb/psutil/tree/openbsd - so far, builds, and passes some tests - dunno if you want an early pull request or when it's more complete.... Code copied from FreeBSD, then adapted for OpenBSD.

[landryb]

Right now... let me know if you want separate files for implems, or everything stashed in _psutil_bsd.c with dozens of #ifdefs.

Ran 193 tests in 8.479s

FAILED (failures=9, errors=42, skipped=68)

[giampaolo]

This is truly awesome and certainly a pretty big task (and feature). If the OpenBSD implementation doesn't differ too much then I'd say stashing everything into _psutil_bsd.c would be better but feel free to work into a separate file for now if it suits you better and then you/we can decide whether to leave it as-is.
The only way this would be accepted is if all (or almost all) features currently implemented for FreeBSD gets translated for OpenBSD and all (or almost all) tests pass. 42 errors means this is not ready for inclusion yet but it's cool to see some work has already been done. I would also be willing to give you some help if necessary. Would you be able to give me access to the OpenBSD box perhaps? I'm also thinking about long-term support: given that I don't have access to that kind of OS I'm a bit worried for the future. Assuming this gets completed would you be willing to maintain OpenBSD support in the future?

[landryb]

I know for sure some features wont be possible for OpenBSD:

• we dont do a distinction between logical and physical CPUs for example, or have no simple way to get that info from userspace so far. I can go the easy route and make them both return the same values.
• there's no way to get the full path of the executable for a process, as this is considered a security/privacy concern iirc. Ie there's no equivalent to KERN_PROC_PATHNAME, so process.exe() will only return the process name if the process has changed its default value from argv[0].
• net_connections is currently disabled/unimplemented, but only because that was a big part and i wanted to have something building quickly. This is a short TODO item.
• disk_io_counters & net_io_counters are also a short TODO item.
• i need to look at fstat code to get the open files/cwd for processes
• some features might only be accessible to root for kvm access - not sure which yet

What i've tested so far with my code and know works:
cpu_count(), cpu_times(), cpu_percent() (need to do percpu..), virtual_memory(), disk_partitions(), disk_usage(), users(), boot_time(), pids(), pid_exists()... Popen wrapper seems to work too.

swap_memory() returns bogus values but that's probably an overflow in my code.
wait_procs() doesnt seem to work, Process class doesnt work yet for missing cwd.

As for giving access to an openbsd box, i dont really have disposable ones where i could safely gave access to someone else - but that's fairly easy to install OpenBSD within kvm or virtualbox or whatever other virtualization solution.. or you can get a free shell on an OpenBSD shared shellbox like devio.us - they usually provide basic build environment which would allow you to quickly test things.

On the long term, if i get notified in advance that some API is to be added/has to be implemented, i can have a look at it and see if it's doable on OpenBSD, no problem with that. I've already written similar code for xfce4-taskmanager for example......

[landryb]

Down to

FAILED (failures=11, errors=33, skipped=68)

after my last commits. One thing is sure, there will be no way to get paths for open files, cwd, or the executable.

[landryb]

So i've resumed working on this in https://github.com/landryb/psutil/tree/openbsd, merged last changes on master and fixing on top of this.

I used to be able to run the tests but probably after the changes from #578 it fails with version mismatch, while i have no other version of psutils..

creating /home/landry/.local/lib/python2.7/site-packages/psutil-3.0.0-py2.7-openbsd-5.6-amd64.egg
Extracting psutil-3.0.0-py2.7-openbsd-5.6-amd64.egg to /home/landry/.local/lib/python2.7/site-packages
psutil 3.0.0 is already the active version in easy-install.pth

Installed /home/landry/.local/lib/python2.7/site-packages/psutil-3.0.0-py2.7-openbsd-5.6-amd64.egg
Processing dependencies for psutil==3.0.0
Finished processing dependencies for psutil==3.0.0
python2.7 test/test_psutil.py
Traceback (most recent call last):
  File "test/test_psutil.py", line 49, in <module>
    import psutil
  File "/home/landry/.local/lib/python2.7/site-packages/psutil-3.0.0-py2.7-openbsd-5.6-amd64.egg/psutil/__init__.py", line 184, in <module>
    raise ImportError(msg)
ImportError: version conflict: '/home/landry/.local/lib/python2.7/site-packages/psutil-3.0.0-py2.7-openbsd-5.6-amd64.egg/psutil/_psutil_bsd.so' C extension module was built for another version of psutil (different than 3.0.0)

[landryb]

Fixed in 3432cee, now i'm at

FAILED (failures=12, errors=34, skipped=67)

Which i think isnt so bad. That's what happens when stuff bitrots and isnt merged quickly...

[landryb]

And after my last commit in 54fa691, it also works on OpenBSD/i386 (32 bits)

FAILED (failures=12, errors=37, skipped=67)

[giampaolo]

I will not have time to look into this for a while 'cause I'm in the US (at least for another month). FWICT 12 failures and 37 errors are still too much. We should try to address if not all at least most of those before including any of this. Also, it looks there's a lot of code in common with FreeBSD. That seems to suggest that the final version of this work will use a single _psutil_bsd.c file with occasional ifdefs here and here, or maybe have _psutil_bsd.c include a new arch/openbsd/platf.c.
When I'll be back to Italy I will install OpenBSD on virtualbox and try to see what I can do. I just wanted to let you know that this is something which will take a while to address on my part.

[landryb]

Yeah, same from my side, i wont have time to work on it until july/august. Just wanted to make sure work isnt lost....

[giampaolo]

Update here: #615 (comment)