Pavel Emelianov wrote: > 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. > > > Agree. int fd is a *file* descriptor, i.e. a number that describes > a file, which is a struct file essentially. That's the way pids must > be represented. E.g. the pid_t is a number, that references some > kernel-space object. This object is to be called somehow more > descriptive than just struct pid. > > Maybe it's worth renaming struct pid into struct pid_struct to > represent the fact, that this is a pid, but also a structure? it helps struct name only. while fields should be renamed as well somehow. Kirill _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
