[Devel] Re: [RFC][PATCH] rename 'struct pid'

[Pavel Emelianov]

Dave Hansen wrote:
> On Tue, 2007-04-10 at 22:52 -0600, Eric W. Biederman wrote:
>> Dave Hansen <hansendc at 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.

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?

>>> 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.
> 
> I think this is more indicative of the great design of 'struct pid' in
> concept.  It truly is a drop-in replacement for how things were used in
> the past.  The concept is *great*.
> 
>> 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.
> 
> I agree that there's no fundamental problem with the structure.  Its
> function is quite ideal.  The issue for me comes in the ability for
> people to update, enhance and review what is going on.  There's no
> fundamental barrier here, as Suka demonstrated getting some of his
> pidspace code to work.  It just crossed my pain threshold as I was
> trying to debug some of it.
> 
> Once we get pidspaces fully working, the hacking in the guts will
> certainly be reduced.  But, there are always bugs, and this is a common
> enough code area that people are bound to touch it as time goes on.  I
> just want to make that as easy as possible.
> 
>> 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.
> 
> I'm completely sure that you'll grasp the entire concept, no matter to
> what we change the names.  The mess that you've unraveled so far in
> there makes has given me supreme confidence in this. :)
> 
> My worry is the ramp-up time for people who want to understand it enough
> hack it or just audit the code, but who won't grasp it on quite the same
> level that you have.  
> 
> -- Dave
> 
> _______________________________________________
> Containers mailing list
> Containers at lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/containers
> 
> _______________________________________________
> Devel mailing list
> Devel at openvz.org
> https://openvz.org/mailman/listinfo/devel
>