On 10/30/2015 10:25 PM, Vladimir Sementsov-Ogievskiy wrote:
On 30.10.2015 08:56, Xiao Guangrong wrote:Currently, file_ram_alloc() only works on directory - it creates a file under @path and do mmap on it This patch tries to allow it to work on file directly, if @path is a directory it works as before, otherwise it treats @path as the target file then directly allocate memory from it Signed-off-by: Xiao Guangrong <guangrong.xiao@xxxxxxxxxxxxxxx> --- exec.c | 80 ++++++++++++++++++++++++++++++++++++++++++------------------------ 1 file changed, 51 insertions(+), 29 deletions(-) diff --git a/exec.c b/exec.c index 3ca7e50..f219010 100644 --- a/exec.c +++ b/exec.c @@ -1174,14 +1174,60 @@ void qemu_mutex_unlock_ramlist(void) } #ifdef __linux__ +static bool path_is_dir(const char *path) +{ + struct stat fs; + + return stat(path, &fs) == 0 && S_ISDIR(fs.st_mode); +} + +static int open_file_path(RAMBlock *block, const char *path, size_t size)I think the name should be more descriptive, as it is very special function in common exec.c and it doesn't "just open file path'.. May be open_ram_file_path
Okay, good to me. :)
+{ + char *filename; + char *sanitized_name; + char *c; + int fd; + + if (!path_is_dir(path)) { + int flags = (block->flags & RAM_SHARED) ? O_RDWR : O_RDONLY; + + flags |= O_EXCL; + return open(path, flags); + }Was not there old scenarios when path is file? statfs will success for any file withing mounted filesystem.
Yes. The old scenarios will create a temporary file under the @path that stop regular file's work.
Also, may be we shouldn't warn about "Memory is not allocated from HugeTlbfs.\n" in case of !path_is_dir ?
A file from hugetlbfs and attach it as backend memory is a valid case to users. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
