From: Petr Vorel <pvorel@suse.cz>
To: Cyril Hrubis <chrubis@suse.cz>
Cc: ltp@lists.linux.it
Subject: Re: [LTP] [PATCH 1/5] hugemmap: Move MNTPOINT definition to header
Date: Fri, 10 May 2024 14:59:18 +0200 [thread overview]
Message-ID: <20240510125918.GA430715@pevik> (raw)
In-Reply-To: <ZjzwBy0g2pRvqW0y@yuki>
Hi Cyril,
first, thanks a lot for looking into this.
> Hi!
> > Also, change it from "hugetlbfs/" to the usual "mntpoint".
> Isn't that actually a regression? The name was more descriptive when it
> was hugetlbfs/...
I agree with a readability point.
From following library code in lib/tst_test.c I expect we mount only once:
if (!!tst_test->needs_rofs + !!tst_test->needs_devfs +
!!tst_test->needs_device + !!tst_test->needs_hugetlbfs > 1) {
tst_brk(TBROK,
"Two or more of needs_{rofs, devfs, device, hugetlbfs} are set");
}
Therefore it's really only readability point due .needs_hugetlbfs (but again,
I agree with it, I guess you want to see the path in the test output and dmesg
logs or when directory is not umounted due bug, right?)
Is there any other .mntpoint value which should be preserved as a different
(I suppose no, but maybe I overlooked)?
BTW without this specific hugetlbfs case I would even suggest to use always
MNTPOINT in whole source tree and remove tst_test->mntpoint (but that might be
also step back - readability might suffer).
> I guess that it makes sense to move the MNTPOINT to the hugetlb.h but I
> would keep the actual directory name the same...
E.g. in hugetlb.h:
#define MNTPOINT "hugetlbfs/"
nit: IMHO it can be just "hugetlbfs"? tst_creat_unlinked calls:
snprintf(template, PATH_MAX, "%s/ltp_%.3sXXXXXX",
path, tid);
=> there is / after %s which is path parameter.
... and in tst_test.h:
#ifndef MNTPOINT
# define MNTPOINT "mntpoint"
#endif
This should be safe, because hugetlb.h includes tst_test.h.
> I would have defined MNTPOINT in the tst_test.h rather than in tst_fs.h.
(from your other email)
But what about OVL_BASE_MNTPOINT in tst_fs.h? I guess all of these should be on
the same place, right? (in 1st commit)
Kind regards,
Petr
--
Mailing list info: https://lists.linux.it/listinfo/ltp
next prev parent reply other threads:[~2024-05-10 12:59 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-31 18:06 [LTP] [PATCH 0/5] MNTPOINT macro cleanup Petr Vorel
2024-01-31 18:06 ` [LTP] [PATCH 1/5] hugemmap: Move MNTPOINT definition to header Petr Vorel
2024-05-09 15:47 ` Cyril Hrubis
2024-05-10 12:59 ` Petr Vorel [this message]
2024-01-31 18:06 ` [LTP] [PATCH 2/5] tree: Define MNTPOINT in include/tst_fs.h Petr Vorel
2024-01-31 18:06 ` [LTP] [PATCH 3/5] tree: Reuse MNTPOINT definition Petr Vorel
2024-01-31 18:06 ` [LTP] [PATCH 4/5] tree: Use MNTPOINT macro instead of string Petr Vorel
2024-01-31 18:06 ` [LTP] [PATCH 5/5] doc/C-API: Update MNTPOINT related examples Petr Vorel
2024-05-09 16:18 ` [LTP] [PATCH 0/5] MNTPOINT macro cleanup 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=20240510125918.GA430715@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