[CRIU] Re: [PATCH 2/3] restore: Don't close LAST_PID_PATH
descriptor if it was not opened
Stanislav Kinsbursky
skinsbursky at parallels.com
Mon Mar 12 04:14:21 EDT 2012
05.03.2012 19:41, Cyrill Gorcunov пишет:
> On Mon, Mar 05, 2012 at 07:29:38PM +0400, Pavel Emelyanov wrote:
>>>
>>> static inline int fork_with_pid(int pid, unsigned long ns_clone_flags)
>>> {
>>> + struct cr_clone_arg ca = { };
>>
>> What for?
>>
>
> This is a good practice to zeroify structures on stack id they
> are not inited via (struct){...} somewhere else or passed into
> function which initizlize it. I think I've overdone here, I'll
> drop this snippet and update the patch.
>
>>> int ret = -1;
>>> char buf[32];
>>> - struct cr_clone_arg ca;
>>> void *stack;
>>>
>>> pr_info("Forking task with %d pid (flags %lx)\n", pid, ns_clone_flags);
>>> @@ -1246,10 +1246,9 @@ static inline int fork_with_pid(int pid, unsigned long ns_clone_flags)
>>> goto err;
>>> }
>>>
>>> - snprintf(buf, sizeof(buf), "%d", pid - 1);
>>> - ca.pid = pid;
>>> - ca.clone_flags = ns_clone_flags;
>>> - ca.fd = open(LAST_PID_PATH, O_RDWR);
>>> + ca.pid = pid;
>>> + ca.clone_flags = ns_clone_flags;
>>> + ca.fd = open(LAST_PID_PATH, O_RDWR);
>>
>> In general I don't appreciate such style of assignments.
>
> Sure I'll not toss this lines in new version, but in general
> I think this style of assignment a way more convenient to
> read and parse by eyes. So if you don't mind I'll continue
> using it (if there is strong disagreement -- then sure I'll
> stop using this style).
>
From my POW the problem here is not in the style you are trying to invent, but
in the attention you are paying to such things.
I believe that these style efforts are minor - especially comparing to other
pending tasks in "TODO" list.
IOW, energy, spent on code cleaning, have to be balanced with the energy, spend
on the project development. The project is still to raw to clean it all the time
just for cleanness itself.
This is just my opinion. And I'm sorry, if it's offensive.
--
Best regards,
Stanislav Kinsbursky
More information about the CRIU
mailing list