Quoting Pavel Emelianov (xemul@xxxxxxxxxx): > Serge E. Hallyn wrote: > > Quoting Eric W. Biederman (ebiederm@xxxxxxxxxxxx): > >> "Serge E. Hallyn" <serue@xxxxxxxxxx> writes: > >> > >>> Quoting Pavel Emelianov (xemul@xxxxxxxxxx): > >>>> The set of functions process_session, task_session, process_group > >>>> and task_pgrp is confusing, as the names can be mixed with each other > >>>> when looking at the code for a long time. > >>>> > >>>> The proposals are to > >>>> * equip the functions that return the integer with _nr suffix to > >>>> represent that fact, > >>>> * and to make all functions work with task (not process) by making > >>>> the common prefix of the same name. > >>>> > >>>> For monotony the routines signal_session() and set_signal_session() > >>>> are replaced with task_session_nr() and set_task_session(), especially > >>>> since they are only used with the explicit task->signal dereference. > >>>> > >>>> I've sent this before, but Andrew didn't include it, so I resend it > >>>> as the part of this set. > >>>> > >>>> Signed-off-by: Pavel Emelianov <xemul@xxxxxxxxxx> > >>>> Acked-by: Serge E. Hallyn <serue@xxxxxxxxxx> > >>> Yup, I still like this patch. > >> I'm borderline. Less error prone interfaces sound good, less > >> duplication of information sounds good. Changing the names of > >> historical function may be change for the sake of change and > >> thus noise. > >> > >> However if we are going to go this far I think we need to remove > >> the numeric pid cache from the task_struct. > > > > You mean tsk->pid? > > > > I agree, especially in Suka's version. Not sure it applies to Pavel's > > version, though since the "real"/global pid is still stored only in > > tsk->pid, right? > > No. All objects that have pid (task_struct, signal_struct and pid (struct)) > have two ids after this patch - virtual one and global one. (Yes, so wouldn't removing task->pid be pretty detrimental?) Could you outline how you would extend this to 3 levels? Would you just add a 'vpid2' etc to the struct pid? thanks, -serge _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
