> [... pg_jobc ...] > I see 3 ways forward...
I count 4, but maybe kre is counting two of them as subclasses of a single one. > simply drop the KASSERT the way that FreeBSD have done, and let > things return to the semi-broken but rarely bothersome code that was > there before. > Or, we could properly define what pg_jobc is counting, and then make > sure that it counts whatever that is properly [...] > Another (more radical) approach would be to simply drop orphanpg() > completely, and thus no longer need pg_jobc at all. > Third, and the option I'd suggest, is to revert to more basic > principles, remove the pg_jobc attempt to detect when a session > leader has exited, or changed to a different process group, and > instead at candidate events (any time a process leaves a process > group, for any reason) check if that process was the session leader, > and if it is, clean up any now orphaned stopped processes. Not surprisingly in view of who put it forward, I would agree with this suggestion. But that alone isn't worth an email. The main thing prompting me to write this mail is > We can even leave pg_jobc in the pgrp struct, to avoid needing a > kernel version bump (and for reasons I cannot imagine, pg_jobc is > copied into kinfo and einfo structs for sysctl and /proc access to > the process data, so leaving it around avoids needing to version > those interfaces as well ... the value would be a meaningless 0, > always, but I really find it hard to believe that anything would ever > care, or even notice). It seems to me that if pg_jobc is exported, someone presumably once cared and there's thus a decent chance someone still cares. Did you do a sweep for userland references to it? It seems plausible to me that it's used, at least for zero/nonzero, by userland tools that are interested in process groups. Is there any record of who added the code to export pg_jobc to userland? If so, and if that person is still around, it might be worth sending a question thataway to see if any explanation might be forthcoming. /~\ 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
