Ztop's current MSRV policy is basically "The oldest possible, and never raise it without considering it a breaking change". That's a reasonable policy for a library crate, but not for a binary crate. Instead, since Ztop's consumers are OS package managers, Ztop should define its MSRV to be the oldest Rust compiler in any supported OS. Currently, that's:

• 1.55.0 for FreeBSD. https://www.freshports.org/lang/rust/

But if we gain Linux support, we should track a few others. @guygastineau what should ztop assume about the lowest Rust version in common Linux distros?

I wonder if you want cargo fmt used on the codebase? There are substantial modifications to some files when used. If you want it I will make a PR just for formatting, and I will then cargo fmt any work that I push elsewhere. If you don't want to enforce formatting then I will just try to use sensible conventions that fit with your style in my work without running the tool.

• Don't print warnings about unknown stats in a release build
• Don't print warnings about the new zil stats, for example "zil_itx_count", in the most recent FreeBSD head.

Sponsored by: Axcient

On FreeBSD 12.2, they aren't. Also, improve the OS-specific tests:

• More modularity
• Don't require the zfs kmod to be loaded during the tests
• Test using canned data from both FreeBSD 12.2 and 13.0.

Fixes #4

On FreeBSD 12, ztop panics like this:

thread 'main' panicked at 'assertion failed: `(left == right)`
  left: `"objset-0xe751ca"`,
 right: `"objset-0x402343"`', src/app/freebsd.rs:53:13
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

The cause is the lack of nunlinked and nunlinks fields in FreeBSD 12's ZFS dataset stats. Shouldn't be too hard to fix.

I spent a little time this evening to explore benchmarks for the backend, but this being a binary only crate I cannot figure out how to call any code from the linux module outside of the binary crate itself :/

Originally posted by @guygastineau in https://github.com/asomers/ztop/issues/13#issuecomment-957069977

Once I stopped resisting the architecture and pretending Rust is Haskell the solution just fell into place ;)

I should implement tests. Luckily, we can test with a mock procfs! Preliminarily I have run it with cargo run on my machine and the outputs were sensible given the workloads I was running. It was strange that I didn't see any activity when I did a ZFS send, but it might have been cached already from using rsync before the send.

It is outside the scope of this PR, but by conditionally supplying the zfs_stats_path this code should work on BSD too. Once this PR is finished and merged I will investigate on my FreeBSD machine. It seems like a lot of complexity can be removed (sorry off topic).

I'll need to merge the cargo fmt commits into this (I haven't run it on the code base yet anyway). I also need to run clippy.

Closes #9

PS. I can rebase a couple commits out where I was trying to do this the wrong way.

I wish I was smart enough to actually fix and submit a patch, but the best I can do is show you errors.

   Compiling ztop v0.1.1 (/home/fryfrog/git/ztop)
error[E0433]: failed to resolve: use of undeclared type `SnapshotIter`
  --> src/app.rs:68:9
   |
68 |         SnapshotIter::new(pool)
   |         ^^^^^^^^^^^^ use of undeclared type `SnapshotIter`

error[E0412]: cannot find type `SnapshotIter` in this scope
  --> src/app.rs:67:47
   |
28 | struct Snapshot {
   | --------------- similarly named struct `Snapshot` defined here
...
67 |     pub fn iter(pool: Option<&str>) -> Result<SnapshotIter, Box<dyn Error>> {
   |                                               ^^^^^^^^^^^^
   |
help: a struct with a similar name exists
   |
67 |     pub fn iter(pool: Option<&str>) -> Result<Snapshot, Box<dyn Error>> {
   |                                               ^^^^^^^^
help: you might be missing a type parameter
   |
38 | impl<SnapshotIter> Snapshot {
   |     ^^^^^^^^^^^^^^

error[E0599]: no associated item named `CLOCK_UPTIME` found for struct `nix::time::ClockId` in the current scope
   --> src/app.rs:111:51
    |
111 |             let boottime = clock_gettime(ClockId::CLOCK_UPTIME).unwrap();
    |                                                   ^^^^^^^^^^^^
    |                                                   |
    |                                                   associated item not found in `nix::time::ClockId`
    |                                                   help: there is an associated constant with a similar name: `CLOCK_BOOTTIME`

Some errors have detailed explanations: E0412, E0433, E0599.
For more information about an error, try `rustc --explain E0412`.

Feel free to just close if you don't want this sort of not very helpful help. :)