tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: pg_jobc going negative?



>> 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		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B


Home | Main Index | Thread Index | Old Index