From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andy Lutomirski Subject: Re: [RFC 1/3] procfs: fdinfo -- Extend information about epoll target files Date: Tue, 21 Feb 2017 10:41:12 -0800 Message-ID: References: <20170221171254.954209904@openvz.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: In-Reply-To: <20170221171254.954209904-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org> Sender: linux-api-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Cyrill Gorcunov Cc: Linux FS Devel , "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Linux API , Al Viro , Andrew Morton , Andrew Vagin , Pavel Emelyanov , Michael Kerrisk , Kirill Kolyshkin , Jason Baron , Andrey Vagin List-Id: linux-api@vger.kernel.org On Tue, Feb 21, 2017 at 8:59 AM, Cyrill Gorcunov wrote: > Since it is possbile to have same number in tfd field (say > file added, closed, then nother file dup'ed to same number > and added back) it is imposible to distinguish such target > files solely by their numbers. > > Strictly speaking regular applications don't need to recognize > these targets at all but for checkpoint/restore sake we need > to collect targets to be able to push them back on restore > in proper order. > > Thus lets add file position, inode and device number where > this target lays. This three fields can be used as a primary > key for sorting, and together with kcmp help CRIU can find > out an exact file target (from the whole set of processes > being checkpointed). I have no problem with this, but I'm wondering whether kcmp's ordered comparisons could also be used for this purpose.