public inbox for ltp@lists.linux.it
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox