Date: Fri, 10 Jul 2020 09:54:25 -0400 (EDT)
From: Mouse <mo...@rodents-montreal.org>
Message-ID: <202007101354.jaa16...@stone.rodents-montreal.org>
| > I see 3 ways forward...
|
| I count 4, but maybe kre is counting two of them as subclasses of a
| single one.
Maybe, no-one said I could count (and the "I see 3" was added before
I started enumerating them...)
| 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". That is, simply maintaining
the available data, rather than evaluating its usefulness.
| Did you do a sweep for userland references to it?
I didn't, but you're right, I should have ... and now have.
| 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
If given "ps -o jobc" that field is printed. It is also included
with "ps -j" output.
The only other references I can see are in libkvm (making the data
available that way) and the kernel.
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?
| Is there any record of who added the code to export pg_jobc to
| userland?
The earliest reference I can find is when cgd created (the no longer existing)
kern_kinfo.c in 1993 - pg_jobc was copied into the einfo struct (e_jobc) in
that version kern_kinfo.c 1.1 - changes after that have moved the code around,
but there's been no change of substance (to the exporting code). I'm not
sure where to look for the corresponding (now deleted) early kinfo code (it
was all moved into init_sysctl.c when that was created in 2003, and then
later moved out to kern_proc.c)
That is, I'd say it comes from CSRG BSD code, and we'd need to delve back
into their sccs archives to see when it was first done (and hopefully, why).
kre
