All of lore.kernel.org
 help / color / mirror / Atom feed
From: Petr Vorel <pvorel@suse.cz>
To: Cyril Hrubis <chrubis@suse.cz>
Cc: ltp@lists.linux.it
Subject: Re: [LTP] [PATCH 1/2] lib: tst_test: Add per filesystem mkfs and mount opts
Date: Fri, 7 Jun 2024 12:29:23 +0200	[thread overview]
Message-ID: <20240607102923.GB55162@pevik> (raw)
In-Reply-To: <20240603123455.7968-2-chrubis@suse.cz>

Hi Cyril,

> This commit does:

> * Group the filesystem type, mkfs and mount options into a separate
>   structure

> * Add an array of these structures to be able to define per filesystem
>   mkfs and mount options

> The details on the usage should be hopefully clear from the
> documentation comments for the struct tst_test.

Nice cleanup!

Reviewed-by: Petr Vorel <pvorel@suse.cz>

BTW is this effort somehow related to Martin's suggestion to "combine
.all_filesystems + .needs_rofs together"? [1] Or you're still not convinced it'd
be useful?

Also, this reminds me our goal to implement minimal filesystem size required per
filesystem.

[1] https://lore.kernel.org/ltp/ad6558e0-e834-4b35-923a-7b519384f436@suse.cz/

...
> +/**
> + * struct tst_fs - A file system type, mkfs and mount options
> + *
> + * @fs_type A filesystem type to use.
nit: @type.

Unfortunately sphinx does not complain when building docs, but you can see
"undescribed" in the resulted html.

> + *
> + * @mkfs_opts: A NULL terminated array of options passed to mkfs in the case
> + *             of 'tst_test.format_device'. These options are passed to mkfs
> + *             before the device path.
> + *
> + * @mkfs_size_opt: An option passed to mkfs in the case of
> + *                 'tst_test.format_device'. The device size in blocks is
> + *                 passed to mkfs after the device path and can be used to
> + *                 limit the file system not to use the whole block device.
> + *
> + * @mnt_flags: MS_* flags passed to mount(2) when the test library mounts a
> + *             device in the case of 'tst_test.mount_device'.
> + *
> + * @mnt_data: The data passed to mount(2) when the test library mounts a device
> + *            in the case of 'tst_test.mount_device'.
> + */
> +struct tst_fs {
> +	const char *type;
> +
> +	const char *const *mkfs_opts;
> +	const char *mkfs_size_opt;
> +
> +	const unsigned int mnt_flags;
> +	const void *mnt_data;
> +};
...

> - * @dev_fs_type: If set overrides the default file system type for the device and
> - *               sets the tst_device.fs_type.
> + * @fs: If fs.type is set it overrides the default file system type for the
> + *      device. The rest of the parameters describe default parameters for
> + *      mkfs and mount.
>   *
> - * @dev_fs_opts: A NULL terminated array of options passed to mkfs in the case
> - *               of 'tst_test.format_device'. These options are passed to mkfs
> - *               before the device path.
> - *
> - * @dev_extra_opts: A NULL terminated array of extra options passed to mkfs in
> - *                  the case of 'tst_test.format_device'. Extra options are
> - *                  passed to mkfs after the device path. Commonly the option
> - *                  after mkfs is the number of blocks and can be used to limit
> - *                  the file system not to use the whole block device.
> + * @fss: A NULL type terminated array of per file system type options. If

Could this be fs_all (although it can be used also without all_filesystems just to describe more fs)?
Because fss looks confusing a bit (it looks as some abbreviation, thus I would
not match it to fs member).

> + *       tst_test.all_filesystems is not set the array describes a list of
> + *       file systems to test along with parameters to pass to mkfs and mount.

So that one can decide if use .fss instead of .all_filesystems and
.skip_filesystems? I like the flexibility, but it can leads to confusion.

Also it'd be like to 1) use fss in some test 2) have at least trivial library
test.

Also nit: writing it as @all_filesystems formats it red (I'd prefer to be a HTML
link to the member in docs, but no idea how to do it. @Andrea, any idea?)
> + *       If tst_test.all_filesystems is set the mkfs and mount options are
> + *       taken from tst_test.fs unless there is an override for a given
> + *       file system type defined in this array.

Kind regards,
Petr

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

  parent reply	other threads:[~2024-06-07 10:29 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-03 12:34 [LTP] [PATCH 0/2] tst_test per FS options and small cleanup Cyril Hrubis
2024-06-03 12:34 ` [LTP] [PATCH 1/2] lib: tst_test: Add per filesystem mkfs and mount opts Cyril Hrubis
2024-06-03 13:22   ` Andrea Cervesato via ltp
2024-06-07 10:29   ` Petr Vorel [this message]
2024-06-11  9:54   ` Martin Doucha
2024-06-11 11:02     ` Petr Vorel
2024-06-11 11:44       ` Martin Doucha
2024-06-11 12:23         ` Cyril Hrubis
2024-06-11 12:42           ` Martin Doucha
2024-06-11 13:11             ` Cyril Hrubis
2024-06-11 13:16               ` Martin Doucha
2024-06-11 13:18                 ` Cyril Hrubis
2024-06-03 12:34 ` [LTP] [PATCH 2/2] syscalls: quotactl: Move mkfs opts into tst_test Cyril Hrubis

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240607102923.GB55162@pevik \
    --to=pvorel@suse.cz \
    --cc=chrubis@suse.cz \
    --cc=ltp@lists.linux.it \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.