Dave Hansen wrote:
> On Tue, 2007-04-10 at 22:52 -0600, Eric W. Biederman wrote:
> 
>>Dave Hansen <hansendc@us.ibm.com> writes:
>>
>>>>A pid (pid_t or
>>>>struct pid) isn't just an identfier it is a handle to processes.
>>>>struct pid just does so more directly because it is inside the kernel.
>>>
>>>Let's face it, "pid" has a meaning.  It's a number.  It's what you
>>>kill(1).  The meaning has been there for a long, long time.  'struct
>>>pid' is a completely different concept, and it's certainly more than
>>>"just a number".
>>
>>Yes.  "pid" has a meaning.  The meaning is old and well established.
>>That meaning is not just a number, just like a file descriptor is not
>>just a number.
> 
> 
> That's a great example.  Userspace fds are to 'struct file' as pids are
> to 'struct pid', right?
> 
> I actually think 'struct file' is a pretty good name.  Think of what
> do_sys_open() might look like if we called 'struct file' 'struct fd'
> instead and 'fdp' instead of 'filp'.
> 
> We end up with lines like:
> 
> 	fd_install(fd, fdp);
> 
> Which makes it confusing which fd we're dealing with or what the 'fd_'
> in the name refers to, the 'fd' or the 'fdp'.  It makes quite a bit of
> sense to have 'fd' and 'struct file' named quite distinctly.

Totally agree with Dave.
Current code looks like a mess of word 'pid'.

Eric, why do you object so much? it doesn't change any functionality at all
just makes code a bit more readable/clear.

Dave, taskref sounds a bit too much generic for me...
But I can't provide some better name :/

pid		- number
pref (or tref)	- process (task) ref, e.g. pid(filp->f_owner.pref)
pref_struct	- former pid_struct, e.g. struct pref_struct pref;
?

Thanks,
Kirill

_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers