Re: [1/2,v2] fdmap(2)

On 10/12/17, Andrei Vagin [off-list ref] wrote:

I'm agree with your points, but I think you choose a wrong set of data
to make an example of a new approach.

You are talking a lot about statx, but for me it is unclear how fdmap
follows the idea of statx. Let's imagine that I want to extend fdmap to
return mnt_id for each file descriptor?

fdmap() is standalone thing.

Next step is to design fdinfo(2) (?) which uses descriptors from fdmap(2).
Extending structures is done as usual: but version, add new fields to the end.

Or it may be more complex case, when we decided to provide all data
from /proc/pid/fdinfo/X for each descriptor. A set of fields in fdinfo
depends on a type of a file descriptor, it is different for epoll,
signalfd, inotify, sockets, etc.

For inotify file descriptors, there are information about all watches,
so it is not possible to use a fixed size struture to present this data.

Now I didn't look closely at inotify watches but this is done with unions,
zero-length trailing arrays, and other usual stuff. If OpenVZ/Virtuozzo is
doing C/R of inotify then you already have all serializing code.