Dave Hansen wrote: > On Tue, 2007-04-10 at 22:52 -0600, Eric W. Biederman wrote: > >>Dave Hansen <hansendc@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers