Aborts on Centos with:
thread 'main' panicked at 'called Result::unwrap()on anErr value: TypeDepthUnknown', examples/bind_threads.rs:29:9

Btw, using 'hwloc2' instead of 'hwloc'.

lstopo version is:
lstopo 2.2.0

I'm using Macbook Air M1 and AWS linux arm server. Is there support for aarch64 architecutre?

I hacked this together myself this afternoon just to reassure myself the data was there, but I wonder if there's a plan for how to support it properly?

For the record, this involved:

1. changing some u32 to i32 to support referencing the special PCI depths (in Topology, and in the FFI bindings)
2. fixing the mapping in depth_for_type (bug,it skipped over TypeDepthNumaNode and so the index mappings were all off)
3. fixing the ffi for hwloc_topology_set_io_types_filter (bug, it doesn't take an ObjectType)

A bunch of those FFI which take c_uchar probably ought to take i32 to support passing the TypeFilter into them.

In any case, this doesn't really feel like the best way to support PCI devices -- it seems like perhaps rather than threading through positive depths as the existing positive integers in an Ok, and the negative depths as enums in an Err, we ought to support them all in a separate proper enum or something ?

I'm pretty new at Rust, so please bear that in mind. My goal is to see this library to the point where one can pull out the distances between cores on different (possibly sub-)NUMA nodes, as well as to various PCI devices attached to the sockets.

As this repo has not received updates for several years and the author has no recorded public activity on github for the past year, I suspect it is not maintained anymore.

So I've set up a personal fork at https://github.com/HadrienG2/hwloc2-rs (see below) on which I'm applying every non-risky patch from the public forks listed in the network graph, as well as a few fixes/improvements on my own.

@Ichbinjoe if you are still around, please tell me if you would be interested in resuming maintenance of this repo or letting me join you as a maintainer. If I get no reply from your side, I will eventually re-upload my fork as yet another similarly named crate on crates.io...

Trying to run this:

use hwloc2::{Topology, ObjectType};

fn main() {
    let topo = Topology::new().expect("Failed to get topology");
    for parent in topo.objects_with_type(&ObjectType::NUMANode).expect("Failed to get objects") {
    }
}

leads to this crash:

thread 'main' panicked at 'The provided depth 4294967292 is out of bounds.', /home/fpr/local/cargo/registry/src/github.com-1ecc6299db9ec823/hwloc2-2.2.0/src/lib.rs:373:13

Running on: Dell XPS 15 9750 laptop
OS: Debian testing 64-bit
hwloc2 version: 2.2.0
hwloc native version: Tried in Debian with 2.4.0 and in a Nix 20.09 environment with 2.2.0.

Compiling and running the example in the documentation completes successfully with the following output:

*** Objects at level 0
0: Machine ()
*** Objects at level 1
0: Package ()
*** Objects at level 2
0: L3 (9216KB)
*** Objects at level 3
0: L2 (256KB)
1: L2 (256KB)
2: L2 (256KB)
3: L2 (256KB)
4: L2 (256KB)
5: L2 (256KB)
*** Objects at level 4
0: L1d (32KB)
1: L1d (32KB)
2: L1d (32KB)
3: L1d (32KB)
4: L1d (32KB)
5: L1d (32KB)
*** Objects at level 5
0: Core ()
1: Core ()
2: Core ()
3: Core ()
4: Core ()
5: Core ()
*** Objects at level 6
0: PU ()
1: PU ()
2: PU ()
3: PU ()
4: PU ()
5: PU ()
6: PU ()
7: PU ()
8: PU ()
9: PU ()
10: PU ()
11: PU ()

I note that this listing contains no reference to a NUMA node whereas lstopo on my system does. However, it seems that a panic of this form is surely not the correct behaviour in this case.

Reading the hwloc2 documentation, I note that HWLOC_TYPE_DEPTH_NUMANODE along with a number of other virtual depths are represened as negative values. I wonder if there is code attempting to treat them as actual depths. My attempt to work around this issue by using the depth_for_type and related functions for locating a depth value to iterate at also returned strange errors for me.