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. > So, please consider that there are actual kernel developers hacking on > this stuff who are having problem with it. The function of 'struct pid' > is great, it's a wonderful concept. It just needs a slightly different > name in order to more easily relate that concept to those that are > trying to use it. > > If anyone can think of some more incremental ways to do this, or has > other suggestions on how to make it more clear, I'm all ears. So what I have seen are examples down in the guts of the pid hash table that are problematic. And a few complaints about pid_nr. However the conversions I have done and I have looked at have just been a drop in replacement for pid_t except for reference counting issues. That to me at least is rather convincing. So I'm not convinced there is a fundamental problem. Just a bit of a problem in the guts of things where everything seems to have the same name. I'm not at all certain how a different prefix would sort that out. My feeling is that changing this just caters to people who are not going to be able to understand what is going on no matter what the structure is named, and is going to make it harder for me to update the code when I find the time to do it. Eric _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers