On 10/12/17, Andrei Vagin <avagin@xxxxxxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
