Re: Semantics of command_id, process_id, process_to_com, process_tree

["troy d. straszheim" <troy () resophonic com>]

On Fri, Jun 23, 2006 at 04:42:11PM -0400, Valdis.Kletnieks () vt edu wrote:
> On Fri, 23 Jun 2006 15:16:08 EDT, "Frank S Posluszny, III" said:
>
> > > There are also some processes absent from process_to_com entirely,
> > > like processes 7 and 12:
> >
> > Sorry, don't know about that one.
>
> Number *that* low on a Linuxoid kernel is almost certainly a kernel
> thread (see kernel/pid.c and the use of RESERVED_PIDS in alloc_pidmap()
> for all the gory details, but basically, all PIDs under 300 (by default)
> are reserved for kernel threads).   It's quite possible that 7 and 12
> were threads created during boot to do things like scsi initialization
> and so on (on my laptop, PID 8 is kblockd, and 9 is kacpid, then a
> big jump to 117 cqueue and 120 khubd (USB support)).
>
> If you're *really* curious to identify it, you'd have to add instrumentation to
> kthread_create() in kernel/kthread.c and/or the kernel_thread() function in
> arch/<mumble>/kernel/process.c - kernel_thread() calls do_fork() which is
> what will end up assigning the PID to the thread....  You probably don't
> want to instrument do_fork() itself unless you plan to spam yourself with
> printk output for *every* fork() you do.. ;)

I was under the impression that process_id as it appears in the
database is strictly internal to the database, not the pid of the
process on the host:

  mysql> select pid, process_id from process;
  +------+------------+
  | pid  | process_id |
  +------+------------+
  | 5952 |          1 | 
  | 5788 |          2 | 
  |    0 |          3 | 
  | 5953 |          4 | 
  | 5954 |          5 | 
  | 5709 |          6 | 
  |    1 |          7 | 
  | 5562 |          8 | 
  | 5866 |          9 | 

and process_to_com refers to this database process_id, not the
kernel's process id...  or?

-troy