[Libguestfs] [PATCH 3/3] e2fsck-f: change the internal to use e2fsck
Matthew Booth
mbooth at redhat.com
Mon Jan 16 10:01:25 UTC 2012
On 01/13/2012 02:55 PM, Wanlong Gao wrote:
>
> From: Wanlong Gao<gaowanlong at cn.fujitsu.com>
>
> Since we implement the new api e2fsck, just change the
> internal of e2fsck_f to use e2fsck now.
>
> Signed-off-by: Wanlong Gao<gaowanlong at cn.fujitsu.com>
> ---
> daemon/ext2.c | 27 ++++++---------------------
> 1 files changed, 6 insertions(+), 21 deletions(-)
>
> diff --git a/daemon/ext2.c b/daemon/ext2.c
> index b0dc6da..da602cc 100644
> --- a/daemon/ext2.c
> +++ b/daemon/ext2.c
> @@ -325,26 +325,6 @@ do_e2fsck (const char *device,
> ADD_ARG (argv, i, NULL);
>
> r = commandv (NULL,&err, argv);
> - if (r == -1 || r>= 2) {
> - reply_with_error ("%s", err);
> - free (err);
> - return -1;
> - }
> -
> - free (err);
> - return 0;
> -}
> -
> -int
> -do_e2fsck_f (const char *device)
> -{
> - char *err;
> - int r;
> -
> - char prog[] = "e2fsck";
> - if (e2prog (prog) == -1)
> - return -1;
> -
> /* 0 = no errors, 1 = errors corrected.
> *
> *>= 4 means uncorrected or other errors.
> @@ -352,7 +332,6 @@ do_e2fsck_f (const char *device)
> * 2, 3 means errors were corrected and we require a reboot. This is
> * a difficult corner case.
> */
> - r = commandr (NULL,&err, prog, "-p", "-f", device, NULL);
> if (r == -1 || r>= 2) {
> reply_with_error ("%s", err);
> free (err);
> @@ -364,6 +343,12 @@ do_e2fsck_f (const char *device)
> }
>
> int
> +do_e2fsck_f (const char *device)
> +{
> + return do_e2fsck (device, 1, 0);
> +}
> +
> +int
> do_mke2journal (int blocksize, const char *device)
> {
> char *err;
As Rich noted, this would need to set optargs_bitmask here.
I think we could actually entirely remove the non-optargs e2fsck calls
from the daemon without interfering with backwards compatibility in any
meaningful way. We could instead turn these into non-daemon. This would
preserve both API and ABI compatibility. The only situation it would
break would be old library with new appliance, which doesn't sound
likely. It's a question of where to put the shim layer. Rich?
Matt
--
Matthew Booth, RHCA, RHCSS
Red Hat Engineering, Virtualisation Team
GPG ID: D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490
More information about the Libguestfs
mailing list