or "kinds"

Does this suggest that the functionality really belongs in fstat(1) (which also uses libprocstat) instead?

I believe we omit "all rights reserved" now.

I am not sure. I remembered about fstat(8) when I started this, but quick man page look convinced me that fstat(8) is more single-purpose thing than procstat(1), and it also has filters like 'pid'. This would be completely different list mode for fstat output, because one file might have more than one lock acquired, either non-intersecting, or compatible.

So for me adding slightly non-idiomatic command to procstat(1) sound better then making fstat(8) a bigger mess.

I still think that procstat is the better choice, if not adding completely new command, and I do not see adding a new command good idea.

In principle, per-pid filters can be eventually added to procstat advlock, for POSIX-like locks, it is just that they are 1) not very popular 2) not too useful for me as dev IMO.

Maybe note somewhere that len == 0 means, "from start to EOF".

Ok, fair enough. I agree that it doesn't make sense to add a new utility for this purpose.

These offsets seem to be slightly wrong. To me it looks right with the following format string: {T:/%2s %5s %5s %5s %18s %18s %8s %9s %9s %s}