From: Antonios Motakis <antonios.mota...@huawei.com> This is an implementation that ensures that a unique 64bit QID path is generated per file.
Since if a file is unique on the host is determined by both inode and device id, which are 64 and 32 bits respectively, the proper long term fix will be an extension in the 9p protocol allowing for a bigger QID path field. The fix presented here is a 'fallback' solution, within the current limitations of 9p. The first patch is a preparatory change. The main feature of the second patch is that now stat_to_qid can fail. We ensure always the same device is being accessed for each file we advertise, to avoid collisions and leave the interesting parts for the next patches. The third patch implements a hash map that maps the first 16 bits of inode and device id to a 16 bit prefix for the QID path. The last 48 bits are set equal to the last 48 inode bits. This should cover most users, and should keep the hash table used for the mapping very small for 99% of use cases. The fourth patch implements a full mapping, as suggested by Emilio G. Cota, that kicks in if the prefix map method fails. This can happen for example if the host OS does not allocate inodes in a predictable way. In that case, the implementation will allow to keep track of up to 2**48 QID paths. Antonios Motakis (4): 9pfs: V9fsQID: set type of version and path to unsigned 9pfs: check for file device to avoid QID path collisions 9pfs: stat_to_qid: use device as input to qid.path 9pfs: stat_to_qid: implement slow path fsdev/9p-marshal.h | 4 +- hw/9pfs/9p.c | 201 ++++++++++++++++++++++++++++++++++++++++++++++++----- hw/9pfs/9p.h | 21 ++++++ 3 files changed, 205 insertions(+), 21 deletions(-) -- 1.8.3.1