Quoting Dave Hansen (hansendc@us.ibm.com):
> 
> 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

I haven't tested the patch, but I enthusiastically, wholeheartedly,
excitedly agree with this name change.

-serge

(I plan to run some cross-arch tests in the morning)

> 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);
>  
>