[Devel] Re: [PATCH 6/9][cr][v2]: Checkpoint file-locks
Sukadev Bhattiprolu
sukadev at linux.vnet.ibm.com
Wed Jul 28 14:29:50 PDT 2010
Oren Laadan [orenl at cs.columbia.edu] wrote:
>
>
> Sukadev Bhattiprolu wrote:
>> Oren Laadan [orenl at cs.columbia.edu] wrote:
>> | | | > + if (lock) {
>> | > + h->fl_start = lock->fl_start;
>> | > + h->fl_end = lock->fl_end;
>> | > + h->fl_type = lock->fl_type;
>> | > + h->fl_flags = lock->fl_flags;
>> | > + } else {
>> | > + /* Checkpoint a dummy lock as a marker */
>> | > + h->fl_start = -1;
>> | | Maybe designate some constant for this ? e.g. CKPT_FLOCK_NONE ?
>> | In any case, you need a (loff_t) -1 (like in the restore code).
>>
>> Ok. Defining macros CKPT_HDR_SET_MARKER_LOCK() and
>> CKPT_HDR_CHECK_MARKER_LOCK(). Also added the missing (loff_t).
>
> The nice thing about #define CKPT_FLOCK_NONE -1 - see also
> the CKPT_PID_NULL, when defined in checkpoint_hdr.h, is that
> they are intentionally visible to userspace too.
The problem is marker lock is currently identified by two fields:
.fl_start = -1;
.fl_type = FL_POSIX.
so CKPT_FLOCK_NONE appears misleading if it only refers to one field.
Should I say CKPT_FLOCK_NONE_START and CKPT_FLOCK_NONE_TYPE ?
Or, can we make CKPT_CHECK_MARKER_LOCK() and CKPT_SET_MARKER_LOCK()
available to user space ?
Sukadev
_______________________________________________
Containers mailing list
Containers at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers
More information about the Devel
mailing list