Re: Kernel Internals

Dale R. Worley (worley@ariadne.com)
Wed, 29 Jan 1997 14:53:54 GMT


In article <01BC07E5.06DD4180@jmohr.blitz.de> James Mohr <jimmo@blitz.net> writes:
First is where the PID comes from. I understood it to be the entry
in the task[] array. That matches the way other *NIXes do it. That
is, the PID is just the offset into the process table (task[]
array). However, I cannot find anything definitive that says this.

It is unlikely that this is the case, since PIDs run the range from 1
to 32767, or so. Most likely, the PID is an entry in the process
structure in the kernel. If you really want to track it down, look
through the code that implements fork() (kernel/fork.c), as that is
the only way that new processes are created.

I am unclear about the differences between bdflush and update. I
understand that bdflush is "part" of update and per the man-page is
"called by a user without superuser priveledges." Do I take this to
mean that processes not owned by root call bdflush and the others
call update?

I don't understand it fully myself, but it is all part of a system
process that you must have (in order to get changed buffers flushed
back to disk regularly) but otherwise you don't have to worry about
it.

Some one said that "Clearing the process table slot of an exiting
process is not the responsability of init, but of the parent. If
all the forefathers have died, init will take over." To me that
says that if I write a simple "Hello, World!" program, it will have
the code to clean up the process table. (maybe in a dynamically
linked library) To me that is system work and the parent process
should do it.

The process table slot is cleared when the "parent" process does a
wait() call which gets the information regarding the exiting of the
process. If a process's parent exists, all of its child processes
automagically become children of process 1, which is init. Since init
almost always is doing a wait() (look at sys_wait4() in
kernel/exit.c), this happens promptly after the process exits.

When I do a ps, I see that more than open process is waiting on
read_chan. No problem. What annoys me is that when I look at the
numeric output for the WCHAN, they are all the same one. Other
UNIXes will have a different WCHAN for each tty that is being
waited upon. Therefore, the number here is different.

That is a statement, not a question. There is probably no reason for
WCHAN values to be handled similarly in different Unixes.

Dale

--
Dale R. Worley					Ariadne Internet Services
Voice: +1 617-899-7949   Fax: +1 617-899-7946	E-mail: worley@ariadne.com
"Internet-based electronic commerce solutions to real business problems."