search for: display_path

...nsertions(+), 2 deletions(-) diff --git a/daemon/file.c b/daemon/file.c index e0f8794..91746e0 100644 --- a/daemon/file.c +++ b/daemon/file.c @@ -483,7 +483,6 @@ pread_fd (int fd, int count, int64_t offset, size_t *size_r, if (close (fd) == -1) { reply_with_perror ("close: %s", display_path); - close (fd); free (buf); return NULL; } @@ -539,7 +538,6 @@ pwrite_fd (int fd, const char *content, size_t size, int64_t offset, if (close (fd) == -1) { reply_with_perror ("close: %s", display_path); - close (fd); return -1; } -- 1.7.6

...zcat); @@ -449,85 +448,6 @@ do_pwrite_device (const char *device, const char *content, size_t size, return pwrite_fd (fd, content, size, offset, device, 1); } -/* This runs the 'file' command. */ -char * -do_file (const char *path) -{ - CLEANUP_FREE char *buf = NULL; - const char *display_path = path; - const int is_dev = STRPREFIX (path, "/dev/"); - struct stat statbuf; - - if (!is_dev) { - buf = sysroot_path (path); - if (!buf) { - reply_with_perror ("malloc"); - return NULL; - } - path = buf; - - /* For non-dev, check this is a regular f...

...97 100644 --- a/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c +++ b/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c @@ -265,6 +265,7 @@ static struct atom_display_object_path_v2 *get_bios_object( && id.enum_id == obj_id.enum_id) return &bp->object_info_tbl.v1_4->display_path[i]; } + /* fall through */ case OBJECT_TYPE_CONNECTOR: case OBJECT_TYPE_GENERIC: /* Both Generic and Connector Object ID @@ -277,6 +278,7 @@ static struct atom_display_object_path_v2 *get_bios_object( && id.enum_id == obj_id.enum_id) return &bp->object_info_tbl....

This is a possibly better work-around for bug 769304, the bug where blkid runs from udev whenever a device closes, causing the subsequent operation to fail. For background to this change, see: https://rwmj.wordpress.com/2012/01/19/udev-unexpectedness/#content So far we have noticed this problem in two places (although I'm fairly certain it affects many more): - in virt-resize, after

...vers/gpu/drm/amd/display/dc/bios/bios_parser2.c > @@ -265,6 +265,7 @@ static struct atom_display_object_path_v2 *get_bios_object( > && id.enum_id == obj_id.enum_id) > return &bp->object_info_tbl.v1_4->display_path[i]; > } > + /* fall through */ > case OBJECT_TYPE_CONNECTOR: > case OBJECT_TYPE_GENERIC: > /* Both Generic and Connector Object ID > @@ -277,6 +278,7 @@ static struct atom_display_object_path_v2 *get_bios_object( >...

...ile.c b/daemon/file.c index 057e15d..91746e0 100644 --- a/daemon/file.c +++ b/daemon/file.c @@ -525,7 +525,7 @@ do_pread_device (const char *device, int count, int64_t offset, size_t *size_r) static int pwrite_fd (int fd, const char *content, size_t size, int64_t offset, - const char *display_path, int settle) + const char *display_path) { ssize_t r; @@ -541,18 +541,6 @@ pwrite_fd (int fd, const char *content, size_t size, int64_t offset, return -1; } - /* When you call close on any block device, udev kicks off a rule - * which runs blkid to reexamine the device....

This patch series is just FYI at the moment. However it does pass the tests. The daemon is a self-contained program. We don't need to write it all in C. Writing parts of it in OCaml would make it simpler and less error-prone. In particular if the daemon was written in a more sane programming language then we could move the inspection code to run entirely inside the appliance, which would

Version 1 was here: https://www.redhat.com/archives/libguestfs/2017-June/msg00003.html This patch series reimplements a few more APIs in OCaml, including some very important core APIs like ?list_filesystems? and ?mount?. All the tests pass after this. The selection of APIs that I have moved may look a little random, but in fact they are all APIs consumed by the inspection code (and some more

v2 was here: https://www.redhat.com/archives/libguestfs/2017-June/msg00008.html This series gets as far as a working (and faster) reimplementation of ‘guestfs_list_filesystems’. I also have another patch series on top of this one which reimplements the inspection APIs inside the daemon, but that needs a bit more work still, since inspection turns out to be a very large piece of code. Rich.

I think this fixes everything mentioned: - Added the Optgroups module as suggested. - Remove command temporary files. - Replace command ~flags with ?fold_stdout_on_stderr. - Nest _with_mounted function. - Rebase & retest. Rich.

v1 was posted here: https://www.redhat.com/archives/libguestfs/2017-July/msg00098.html This series now depends on two small patches which I posted separately: https://www.redhat.com/archives/libguestfs/2017-July/msg00207.html https://www.redhat.com/archives/libguestfs/2017-July/msg00209.html v1 -> v2: - Previously changes to generator/daemon.ml were made incrementally through the patch

Previously posted as part of the mega utilities/inspection series here: https://www.redhat.com/archives/libguestfs/2017-June/msg00232.html What I've done is to extract just the parts related to rewriting daemon APIs in OCaml, rebase them on top of the current master, fix a few things, and recompile and test everything. Rich.

This is a combination of: https://www.redhat.com/archives/libguestfs/2017-June/msg00046.html [PATCH 00/12] Refactor utility functions. plus: https://www.redhat.com/archives/libguestfs/2017-June/msg00023.html [PATCH v3 00/19] Allow APIs to be implemented in OCaml. with the second patches rebased on top of the utility refactoring, and some other adjustments and extensions. This passes

v6 was posted here: https://www.redhat.com/archives/libguestfs/2017-June/msg00103.html and this requires the utilities refactoring posted here: https://www.redhat.com/archives/libguestfs/2017-June/msg00169.html Inspection is now complete[*], although not very well tested. I'm intending to compare the output of many guests using old & new virt-inspector to see if I can find any

v5: https://www.redhat.com/archives/libguestfs/2017-June/msg00065.html Since v5, this now implements inspection almost completely for Linux and Windows guests. Rich.

v7 was: https://www.redhat.com/archives/libguestfs/2017-June/msg00169.html https://www.redhat.com/archives/libguestfs/2017-June/msg00184.html I believe this addresses all comments received so far. Also it now passes a test where I compared about 100 disk images processed with old and new virt-inspector binaries. The output is identical in all cases except one which is caused by a bug in blkid