Add proc_info structs and methods to macOS SystemB

[dbwiddis]

Adds macOS process/socket information structs and methods to c.s.j.p.mac.SystemB.

Most mappings have been in use by OSHI since 2020, finally catching up on my upstream contributions. vm_deallocate (yes I had a memory leak for a decade) and statfs64 are recent additions.

Changes

c.s.j.p.mac.SystemB:

• ProcFdInfo
• InSockInfo
• TcpSockInfo
• proc_pidfdinfo(), statfs64(), vm_deallocate() methods
• Constants: PROC_PIDLISTFDS, PROC_PIDFDSOCKETINFO, PROX_FDTYPE_SOCKET, SOCKINFO_IN, SOCKINFO_TCP, TSI_T_NTIMERS, AF_INET, AF_INET6

Reference headers

• sys/proc_info.h: struct proc_fdinfo, struct in_sockinfo, struct tcp_sockinfo, PROC_PIDLISTFDS, PROC_PIDFDSOCKETINFO, PROX_FDTYPE_SOCKET, TSI_T_NTIMERS

[matthiasblaesing]

I found this: https://github.com/phracker/MacOSX-SDKs/blob/041600eda65c6a668f66cb7d56b7d1da3e8bcc93/MacOSX11.3.sdk/usr/include/sys/proc_info.h#L360-L388

The first members match. Are the latter members intentionally not mapped as struct but instead as byte arrays?

[dbwiddis]

int arrays to be precise.

I knew there was a reason I hadn't contributed these upstream for years... since I didn't really need them in my project I just made sure the byte counts matched as creating a union I would never need was annoying.

So this is four 32-bit IP addresses, the larger member of the first and second unions (thus int[4])

struct in4in6_addr {
	u_int32_t               i46a_pad32[3];
	struct in_addr          i46a_addr4;
};

struct in_addr {
    in_addr_t s_addr;
};

typedef __uint32_t      in_addr_t;      /* base type for internet address */

Similarly with the last insi_v6 structure.

Not sure I want to go to the trouble of mapping them. I can just close this PR. (I guess it's not that hard. I'm just lazy.)

[dbwiddis]

Properly mapped the unions. Made identical changes here: https://github.com/dbwiddis/oshi/tree/jna-union-mapping

And got sane socket info:

Internet Protocol statistics:
 TCPv4: TcpStats [connectionsEstablished=35, connectionsActive=0, connectionsPassive=0, connectionFailures=0, connectionsReset=0, segmentsSent=44072670, segmentsReceived=39606736, segmentsRetransmitted=0, inErrors=17, outResets=0]
 TCPv6: TcpStats [connectionsEstablished=28, connectionsActive=0, connectionsPassive=0, connectionFailures=0, connectionsReset=0, segmentsSent=11068788, segmentsReceived=23792192, segmentsRetransmitted=0, inErrors=0, outResets=0]
 UDPv4: UdpStats [datagramsSent=12698180, datagramsReceived=28394674, datagramsNoPort=0, datagramsReceivedErrors=16]
 UDPv6: UdpStats [datagramsSent=3296969, datagramsReceived=0, datagramsNoPort=0, datagramsReceivedErrors=0]
IPConnection [type=tcp4, localAddress=/127.0.0.1, localPort=54293, foreignAddress=/127.0.0.1, foreignPort=54292, state=ESTABLISHED, transmitQueue=0, receiveQueue=0, owningProcessId=21781]
IPConnection [type=tcp6, localAddress=/2601:601:d47c:3090:e8d5:53bc:e284:8cdb, localPort=53268, foreignAddress=/2607:f8b0:400e:c05:0:0:0:bc, foreignPort=5228, state=ESTABLISHED, transmitQueue=0, receiveQueue=0, owningProcessId=68912]
IPConnection [type=tcp4, localAddress=/10.0.0.143, localPort=53898, foreignAddress=/140.82.113.25, foreignPort=443, state=ESTABLISHED, transmitQueue=0, receiveQueue=0, owningProcessId=68912]
IPConnection [type=udp6, localAddress=/2601:601:d47c:3090:e8d5:53bc:e284:8cdb, localPort=63483, foreignAddress=/2607:f8b0:400a:809:0:0:0:200e, foreignPort=443, state=NONE, transmitQueue=0, receiveQueue=0, owningProcessId=68912]
IPConnection [type=tcp4, localAddress=/10.0.0.143, localPort=54198, foreignAddress=/143.204.160.50, foreignPort=443, state=ESTABLISHED, transmitQueue=0, receiveQueue=0, owningProcessId=68912]

[matthiasblaesing]

The "opaque" elements in SocketInfo could be mapped as structures. On the other hand it should be possible to provide decoder helper for that.

[dbwiddis]

The "opaque" elements in SocketInfo could be mapped as structures. On the other hand it should be possible to provide decoder helper for that.

Yeah, a ton of fields with a nested union with 7 structures in it.

You can see why I skipped it when I didn't need that info. :)

I'll see if I can get to it this weekend.

[matthiasblaesing]

The "opaque" elements in SocketInfo could be mapped as structures. On the other hand it should be possible to provide decoder helper for that.

Yeah, a ton of fields with a nested union with 7 structures in it.

You can see why I skipped it when I didn't need that info. :)

I'll see if I can get to it this weekend.

Just to be clear: This was not a "this must be done" request. If you decide that the current state is sensible, I'm ok with that.

[dbwiddis]

Understood. I'm still going to evaluate the scope and consider if there's a way to map it in a non-breaking way if it needs to be added later.

[dbwiddis]

OK, I looked again after fresh coffee and was confusing myself. I'd already mapped the more complicated one. This last one is a nice flat structure with easy mappings that add up to 136. I'll merge in 24 hours if you don't object.

[matthiasblaesing]

Thank you - great work!