I've been hacking quite a bit on the pidspace code.  I've run
into a bug or two, and had a heck of a time debugging it.
Other than my inferior puny monkey brain, I'm directing some
of the blame squarely in the direction of the 'struct pid'.

We have pid_t, pid_ns, struct pid and pid_link, at _least_.
Seeing code like get_pid(pid->pid_ns->pid_type[PIDTYPE_PID])
is mind-numbing to say the least.  It makes it really hard
to comprehend, and even harder to debug.

We honestly have a lot of code like this:

	pid = pid_nr(filp->f_owner.pid);

WTF?  It's getting a pid from a pid?  Huh? :)

It makes sense when you go look at the structures, but
sitting in the middle of a function and when you can't see
all of the struct declarations can be really sketchy.

So, I propose that we rename the one structure that seems to
be the focus of the problem: 'struct pid'.  Fundamentally, it
is a 'process identifier': it helps the kernel to identifty
processes.  However, as I noted, 'pid' is a wee bit overloaded.

In addition to "identifying" processes, this structure acts
as an indirection or handle to them.  So, I propse we call
these things 'struct task_ref'.  Just reading some of the
code that I've modified in here makes me feel like this is
the right way.

Compare the two sentences below:

Oh, I have a task_ref?  What kind is it?  Oh, it's a pgid
reference because I have REFTYPE_PGID.

Oh, I have a pid?  What kind is it?  Oh, it's a pid because
I have PIDTYPE_PID.

Which makes more sense?

So, this still needs some work converting some of the
function names, but it compiles as-is.  Any ideas for better
names?

Signed-off-by: Dave Hansen <hansendc@us.ibm.com>
---

 lxc-dave/drivers/char/keyboard.c        |   10 +-
 lxc-dave/drivers/char/n_r3964.c         |   32 +++---
 lxc-dave/drivers/char/tty_io.c          |   66 ++++++-------
 lxc-dave/drivers/char/vt.c              |    2 
 lxc-dave/drivers/char/vt_ioctl.c        |   16 +--
 lxc-dave/drivers/net/tun.c              |    2 
 lxc-dave/drivers/s390/char/fs3270.c     |    4 
 lxc-dave/drivers/usb/core/devio.c       |   12 +-
 lxc-dave/drivers/usb/core/inode.c       |    2 
 lxc-dave/drivers/usb/core/usb.h         |    2 
 lxc-dave/files                          |   42 --------
 lxc-dave/fs/autofs/autofs_i.h           |    2 
 lxc-dave/fs/autofs/inode.c              |    4 
 lxc-dave/fs/autofs/root.c               |    2 
 lxc-dave/fs/compat.c                    |    4 
 lxc-dave/fs/dnotify.c                   |    2 
 lxc-dave/fs/exec.c                      |    8 -
 lxc-dave/fs/fcntl.c                     |   63 ++++++-------
 lxc-dave/fs/file_table.c                |    2 
 lxc-dave/fs/ioprio.c                    |   17 +--
 lxc-dave/fs/locks.c                     |    2 
 lxc-dave/fs/ncpfs/inode.c               |   20 ++--
 lxc-dave/fs/proc/array.c                |    2 
 lxc-dave/fs/proc/base.c                 |   52 +++++-----
 lxc-dave/fs/proc/inode.c                |    4 
 lxc-dave/fs/proc/internal.h             |    6 -
 lxc-dave/fs/proc/root.c                 |    4 
 lxc-dave/fs/proc/task_mmu.c             |    4 
 lxc-dave/fs/proc/task_nommu.c           |    5 -
 lxc-dave/fs/smbfs/inode.c               |    8 -
 lxc-dave/fs/smbfs/proc.c                |    4 
 lxc-dave/fs/smbfs/smbiod.c              |   10 +-
 lxc-dave/include/linux/console_struct.h |    2 
 lxc-dave/include/linux/fs.h             |    8 +
 lxc-dave/include/linux/init_task.h      |   22 ++--
 lxc-dave/include/linux/kernel.h         |    4 
 lxc-dave/include/linux/mmzone.h         |    2 
 lxc-dave/include/linux/n_r3964.h        |    2 
 lxc-dave/include/linux/ncp_mount.h      |    2 
 lxc-dave/include/linux/pid.h            |  104 ++++++++++++---------
 lxc-dave/include/linux/proc_fs.h        |    4 
 lxc-dave/include/linux/sched.h          |   42 ++++----
 lxc-dave/include/linux/smb_fs_sb.h      |    2 
 lxc-dave/include/linux/tty.h            |    4 
 lxc-dave/include/linux/vt_kern.h        |    2 
 lxc-dave/init/main.c                    |    2 
 lxc-dave/ipc/mqueue.c                   |    8 -
 lxc-dave/kernel/capability.c            |    8 -
 lxc-dave/kernel/cpuset.c                |   10 +-
 lxc-dave/kernel/exit.c                  |   38 ++++----
 lxc-dave/kernel/fork.c                  |   23 ++--
 lxc-dave/kernel/futex.c                 |    2 
 lxc-dave/kernel/pid.c                   |  152 ++++++++++++++++----------------
 lxc-dave/kernel/rtmutex-debug.c         |    1 
 lxc-dave/kernel/signal.c                |   26 ++---
 lxc-dave/kernel/sys.c                   |   28 ++---
 lxc-dave/kernel/sysctl.c                |   10 +-
 lxc-dave/mm/mempolicy.c                 |    3 
 lxc-dave/mm/migrate.c                   |    2 
 59 files changed, 453 insertions(+), 475 deletions(-)

diff -puN include/linux/pid.h~rename-struct-pid include/linux/pid.h
--- lxc/include/linux/pid.h~rename-struct-pid	2007-04-10 16:18:30.000000000 -0700
+++ lxc-dave/include/linux/pid.h	2007-04-10 16:18:30.000000000 -0700
@@ -3,23 +3,24 @@
 
 #include <linux/rcupdate.h>
 
-enum pid_type
+enum task_ref_type
 {
-	PIDTYPE_PID,
-	PIDTYPE_PGID,
-	PIDTYPE_SID,
-	PIDTYPE_MAX
+	REFTYPE_PID,
+	REFTYPE_PGID,
+	REFTYPE_SID,
+	REFTYPE_MAX
 };
 
 /*
- * What is struct pid?
+ * What is struct task_ref?
  *
- * A struct pid is the kernel's internal notion of a process identifier.
- * It refers to individual tasks, process groups, and sessions.  While
- * there are processes attached to it the struct pid lives in a hash
- * table, so it and then the processes that it refers to can be found
- * quickly from the numeric pid value.  The attached processes may be
- * quickly accessed by following pointers from struct pid.
+ * A 'struct task_ref' is the kernel's internal notion of a process
+ * identifier.  It refers to individual tasks, process groups, and
+ * sessions.  While there are processes attached to it the
+ * 'struct task_ref' lives in a hash table, so it and then the
+ * processes that it refers to can be found quickly from the numeric
+ * pid value.  The attached processes may be quickly accessed by
+ * following pointers from struct task_ref.
  *
  * Storing pid_t values in the kernel and refering to them later has a
  * problem.  The process originally with that pid may have exited and the
@@ -31,89 +32,98 @@ enum pid_type
  * the now useless task_struct is still kept.  A task_struct plus a
  * stack consumes around 10K of low kernel memory.  More precisely
  * this is THREAD_SIZE + sizeof(struct task_struct).  By comparison
- * a struct pid is about 64 bytes.
+ * a struct task_ref is about 64 bytes.
  *
- * Holding a reference to struct pid solves both of these problems.
+ * Holding a reference to struct task_ref solves both of these problems.
  * It is small so holding a reference does not consume a lot of
- * resources, and since a new struct pid is allocated when the numeric pid
+ * resources, and since a new struct task_ref is allocated when the numeric pid
  * value is reused (when pids wrap around) we don't mistakenly refer to new
  * processes.
  */
 
-struct pid
+struct task_ref
 {
 	atomic_t count;
 	/* Try to keep pid_chain in the same cacheline as nr for find_pid */
-	int nr;
+	int pid;
 	struct hlist_node pid_chain;
-	/* lists of tasks that use this pid */
-	struct hlist_head tasks[PIDTYPE_MAX];
+	/*
+	 * lists of tasks that use this pid.
+	 * For instance, ->tasks[REFTYPE_SID]
+	 * has all tasks with a session id of
+	 * the number in ->pid.
+	 */
+	struct hlist_head tasks[REFTYPE_MAX];
 	struct rcu_head rcu;
 };
 
-extern struct pid init_struct_pid;
+extern struct task_ref init_task_ref;
 
 struct pid_link
 {
 	struct hlist_node node;
-	struct pid *pid;
+	struct task_ref *tref;
 };
 
-static inline struct pid *get_pid(struct pid *pid)
+static inline struct task_ref *get_pid(struct task_ref *tref)
 {
-	if (pid)
-		atomic_inc(&pid->count);
-	return pid;
+	if (tref)
+		atomic_inc(&tref->count);
+	return tref;
 }
 
-extern void FASTCALL(put_pid(struct pid *pid));
-extern struct task_struct *FASTCALL(pid_task(struct pid *pid, enum pid_type));
-extern struct task_struct *FASTCALL(get_pid_task(struct pid *pid,
-						enum pid_type));
+extern void FASTCALL(put_task_ref(struct task_ref *tref));
+extern struct task_struct *FASTCALL(pid_task(struct task_ref *tref,
+						enum task_ref_type));
+extern struct task_struct *FASTCALL(get_pid_task(struct task_ref *tref,
+						enum task_ref_type));
 
-extern struct pid *get_task_pid(struct task_struct *task, enum pid_type type);
+extern struct task_ref *get_task_ref(struct task_struct *task,
+				     enum task_ref_type type);
 
 /*
  * attach_pid() and detach_pid() must be called with the tasklist_lock
  * write-held.
  */
-extern int FASTCALL(attach_pid(struct task_struct *task,
-				enum pid_type type, struct pid *pid));
-extern void FASTCALL(detach_pid(struct task_struct *task, enum pid_type));
-extern void FASTCALL(transfer_pid(struct task_struct *old,
-				  struct task_struct *new, enum pid_type));
+extern int FASTCALL(attach_task_ref(struct task_struct *task,
+					enum task_ref_type type,
+					struct task_ref *tref));
+extern void FASTCALL(detach_task_ref(struct task_struct *task, enum task_ref_type));
+extern void FASTCALL(transfer_task_ref(struct task_struct *old,
+					struct task_struct *new,
+					enum task_ref_type));
 
 /*
  * look up a PID in the hash table. Must be called with the tasklist_lock
  * or rcu_read_lock() held.
  */
-extern struct pid *FASTCALL(find_pid(int nr));
+extern struct task_ref *FASTCALL(find_task(int nr));
 
 /*
  * Lookup a PID in the hash table, and return with it's count elevated.
  */
-extern struct pid *find_get_pid(int nr);
-extern struct pid *find_ge_pid(int nr);
+extern struct task_ref *find_get_pid(int nr);
+extern struct task_ref *find_ge_pid(int nr);
 
-extern struct pid *alloc_pid(void);
-extern void FASTCALL(free_pid(struct pid *pid));
+extern struct task_ref *alloc_task_ref(v