[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Libguestfs] [PATCH 3/3] e2fsck-f: change the internal to use e2fsck



On 01/13/2012 02:55 PM, Wanlong Gao wrote:

From: Wanlong Gao<gaowanlong 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 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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]