>> It seems to me that if pg_jobc is exported, someone presumably once >> cared and there's thus a decent chance someone still cares. > Really? I'd have thought it more likely, given the context, that > "it can be obtained via /dev/kmem" -> "it can be fetched via libkvm" > -> "it can be fetched via sysctl/procfs".
But each of those steps involves some winnowing-down. Lots of stuff can be obtained via /dev/kmem that nobody ever looks at in practice and was never available via libkvm (except to the extent that it has an interface that lets its caller specify anywhere in KVM - I don't know libkvm's API). And someone had to translate libkvm to sysctl/procfs, and, in the process, either winnow the available data more or choose to not winnow it more. Either way, that means there were two steps at which someone thought it was valuable enough to export via whichever was then the new interface. >> It seems plausible to me that it's used, at least for zero/nonzero, >> by userland tools that are interested in process groups. > And you're right, it is used, by exactly one userland tool ... ps Did your userland sweep include pkgsrc? I don't know pkgsrc, but I'd be astonished if there aren't at least a few programs there that grub around in things like this. Obviously, there could be non-pkgsrc programs, but it's unreasonable, not to mention impossible, for anyone to check every userland tool anyone's ever thrown together. > ps(1) itself obviously doesn't really care, it is just showing the > info that is made available to it, so we'd only have an actual user > if one of us humans actually finds that output useful for something. > Anyone? Not me. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B