Re: [PATCH 6/9][cr][v2]: Checkpoint file-locks

[Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>]

Oren Laadan [orenl@cs.columbia.edu] wrote:
>
>
> Sukadev Bhattiprolu wrote:
>> Oren Laadan [orenl@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