[PATCH 0/2] xfsprogs: libxcmd: support wildcard for fs_table lookups

[PATCH 0/2] xfsprogs: libxcmd: support wildcard for fs_table lookups

[Alex Elder]

These two patches add support for the use of 0 as a wildcard value
for indicating the type of entry wanted in a fs_table search.  This
allows some code in xfs_quota to be simplified a bit, and (perhaps)
makes it clearer that in most cases searches only look for one type.

					-Alex

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

[PATCH 1/2] xfsprogs: libxcmd: allow 0 as a wildcard fs_table entry type selector

[Alex Elder]

In libxcmd a table is used to represent filesystems and directories
that could be subject to quota operations.  A cursor mechanism is
used to search that table, and it includes a flag that indicates
whether the type of entry desired represents a directory (for project
quotas) or a mount point (otherwise).  It also allows a search for
either type.

There is only call to fs_cursor_initialise() where both mount points
and project paths are requested--all others just requested one or
the other.

Change it so when searching fs_table (in fs_table_lookup() and
fs_cursor_next_entry()), a zero "flags" value is interpreted as a
wildcard, matching either type of entry.

Also add some commentary explaining the use of 0 as a wildcard, and
simplify fs_cursor_next_entry() a bit in the process.

Signed-off-by: Alex Elder <aelder@sgi.com>
---
 libxcmd/paths.c |   28 ++++++++++++++++++++--------
 1 files changed, 20 insertions(+), 8 deletions(-)

diff --git a/libxcmd/paths.c b/libxcmd/paths.c
index 1dbe0be..9ec42ab 100644
--- a/libxcmd/paths.c
+++ b/libxcmd/paths.c
@@ -48,7 +48,7 @@ fs_table_lookup(
 	if (stat64(dir, &sbuf) < 0)
 		return NULL;
 	for (i = 0; i < fs_count; i++) {
-		if ((flags & fs_table[i].fs_flags) == 0)
+		if (flags && !(flags & fs_table[i].fs_flags))
 			continue;
 		if (S_ISBLK(sbuf.st_mode) || S_ISCHR(sbuf.st_mode)) {
 			if (sbuf.st_rdev == fs_table[i].fs_datadev)
@@ -439,6 +439,16 @@ fs_table_insert_project_path(
  * Table iteration (cursor-based) interfaces
  */
 
+/*
+ * Initialize an fs_table cursor.  If a directory path is supplied,
+ * the cursor is set up to appear as though the table contains only
+ * a single entry which represents the directory specified.
+ * Otherwise it is set up to prepare for visiting all entries in the
+ * global table, starting with the first.  "flags" can be either
+ * FS_MOUNT_POINT or FS_PROJECT_PATH to limit what type of entries
+ * will be selected by fs_cursor_next_entry().  0 can be used as a
+ * wild card (selecting either type).
+ */
 void
 fs_cursor_initialise(
 	char		*dir,
@@ -461,17 +471,19 @@ fs_cursor_initialise(
 	cur->flags = flags;
 }
 
+/*
+ * Use the cursor to find the next entry in the table having the
+ * type specified by the cursor's "flags" field.
+ */
 struct fs_path *
 fs_cursor_next_entry(
 	fs_cursor_t	*cur)
 {
-	fs_path_t	*next = NULL;
-
 	while (cur->index < cur->count) {
-		next = &cur->table[cur->index++];
-		if (cur->flags & next->fs_flags)
-			break;
-		next = NULL;
+		fs_path_t	*next = &cur->table[cur->index++];
+
+		if (!cur->flags || (cur->flags & next->fs_flags))
+			return next;
 	}
-	return next;
+	return NULL;
 }
-- 
1.7.6.2

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

[PATCH 2/2] xfsprogs: xfs_quota: kill local variable "type" from free_f()

[Alex Elder]

Only one value is ever really used for the  "type" variable in
free_f(), and it indicates that either type of entry in fs_table
is wanted.  Just get rid of the variable and make use of the
ability to provide 0 to free_space_list() to indicate that.

Signed-off-by: Alex Elder <aelder@sgi.com>
---
 quota/free.c |   12 ++++--------
 1 files changed, 4 insertions(+), 8 deletions(-)

diff --git a/quota/free.c b/quota/free.c
index 71a7cb2..79b52e9 100644
--- a/quota/free.c
+++ b/quota/free.c
@@ -297,14 +297,13 @@ static void
 free_space_list(
 	FILE			*fp,
 	uint			form,
-	uint			type,
 	char			*dir,
 	uint			flags)
 {
 	fs_cursor_t		cursor;
 	fs_path_t		*path;
 
-	fs_cursor_initialise(dir, type, &cursor);
+	fs_cursor_initialise(dir, 0, &cursor);
 	while ((path = fs_cursor_next_entry(&cursor))) {
 		if (free_space(fp, form, path, flags))
 			flags |= NO_HEADER_FLAG;
@@ -318,7 +317,7 @@ free_f(
 {
 	FILE		*fp = NULL;
 	char		*fname = NULL;
-	int		c, flags = 0, form = 0, type = 0;
+	int		c, flags = 0, form = 0;
 
 	while ((c = getopt(argc, argv, "bf:hNir")) != EOF) {
 		switch (c) {
@@ -348,16 +347,13 @@ free_f(
 	if (!form)
 		form = XFS_BLOCK_QUOTA;
 
-	if (!type)
-		type = FS_MOUNT_POINT|FS_PROJECT_PATH;
-
 	if ((fp = fopen_write_secure(fname)) == NULL)
 		return 0;
 
 	if (argc == optind)
-		free_space_list(fp, form, type, NULL, flags);
+		free_space_list(fp, form, NULL, flags);
 	else while (argc > optind)
-		free_space_list(fp, form, type, argv[optind++], flags);
+		free_space_list(fp, form, argv[optind++], flags);
 
 	if (fname)
 		fclose(fp);
-- 
1.7.6.2

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [PATCH 1/2] xfsprogs: libxcmd: allow 0 as a wildcard fs_table entry type selector

[Christoph Hellwig]

Looks good,

Reviewed-by: Christoph Hellwig <hch@lst.de>

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [PATCH 2/2] xfsprogs: xfs_quota: kill local variable "type" from free_f()

[Christoph Hellwig]

On Wed, Sep 28, 2011 at 06:44:34AM -0500, Alex Elder wrote:
> Only one value is ever really used for the  "type" variable in
> free_f(), and it indicates that either type of entry in fs_table
> is wanted.  Just get rid of the variable and make use of the
> ability to provide 0 to free_space_list() to indicate that.

This sounds like someone planned to add an argument to it to support
looking at just normal or project quotas.

Given that it never materialized and no one asked for it I'm fine
with your cleanup.

Reviewed-by: Christoph Hellwig <hch@lst.de>

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs