Displaying 4 results from an estimated 4 matches for "is_device_paramet".
Did you mean:
is_device_parameter
2017 Aug 03
0
[PATCH 3/6] daemon: Refine check for Device and Dev_or_Path parameters (RHBZ#1477623).
For Device parameters we expect a block device name. However we were
only testing for "/dev/..." and so chardevs (from the appliance) could
be passed here, resulting in strange effects. This adds a function
is_device_parameter which tests for a valid block device name.
For Dev_or_Path parameters much the same, except we can also use the
is_device_parameter function elsewhere in the daemon to distinguish if
we were called with a device or path parameter. Previously we used a
simple test if the path begins with "/...
2017 Aug 08
1
Re: [PATCH 3/6] daemon: Refine check for Device and Dev_or_Path parameters (RHBZ#1477623).
...(statbuf.st_mode)) {
> + fprintf (stderr, "S_ISDIR\n");
The two unconditional fprintf() look like debugging leftovers.
> + fd = open (device, O_RDONLY|O_CLOEXEC);
> + if (fd == -1) {
> + if (verbose)
> + fprintf (stderr, "%s: open: %s: %m\n", "is_device_parameter", device);
> + return 0;
> + }
> + if (ioctl (fd, BLKGETSIZE64, &n) == -1) {
> + if (verbose)
> + fprintf (stderr, "%s: ioctl BLKGETSIZE64: %s: %m\n",
> + "is_device_parameter", device);
> + close (fd);
> + retu...
2017 Aug 03
9
[PATCH 0/6] tests: Fix handling of device API parameters (RHBZ#1477623).
https://bugzilla.redhat.com/show_bug.cgi?id=1477623
The first two patches are cleanups.
The third patch changes the way that we handle Device and Dev_or_Path
parameters so that a parameter marked as such can really only contain
a block device name (and not, for instance, a chardev). Using a
chardev here caused hangs in the API.
The next two patches fix API usage to conform to this new stricter
2020 Mar 05
5
[PATCH v2 0/4] daemon: Translate device names if Linux device is unstable (RHBZ#1804207).
v1 was here:
https://www.redhat.com/archives/libguestfs/2020-February/msg00220.html
This patch series is a little bit better. It's still a bit of a hack.
The _real_ fix for this is outlined in the TODO file (see patch 1) but
that requires a lot more work than we could do before 1.42 is
released, unless we delay 1.42 for a lot longer. I'm hoping with this
to have something which works