From: Sam James <sam@gentoo.org>
To: Christoph Hellwig <hch@infradead.org>
Cc: Sam James <sam@gentoo.org>,
linux-xfs@vger.kernel.org, Felix Janda <felix.janda@posteo.de>
Subject: Re: [PATCH v3 2/4] io: Assert we have a sensible off_t
Date: Tue, 26 Dec 2023 20:49:31 +0000 [thread overview]
Message-ID: <87v88k1yeq.fsf@gentoo.org> (raw)
In-Reply-To: <ZYEwFUy6bFO3h7Lz@infradead.org>
Christoph Hellwig <hch@infradead.org> writes:
> On Fri, Dec 15, 2023 at 01:36:41AM +0000, Sam James wrote:
>> + /* We're only interested in supporting an off_t which can handle >=4GiB. */
>
> This adds a < 80 character line. Also I find the wording a bit odd, the
> point is that xfsprogs relies on (it or rather will with your entire
> series), so maybe:
>
> /*
> * xfsprogs relies on the LFS interfaces with a 64-bit off_t to
> * actually support sensible file systems sizes.
> */
>
> And while I'm nitpicking, maybe a better place would be to move this to
> libxfs as that's where we really care. If you use the C99 static_assert
> instead of the kernel BUILD_BUG_ON this can even move outside a function
> and just into a header somewhere, say include/xfs,h. Which actually
> happens to have this assert in an awkware open coded way already:
>
> /*
> * make sure that any user of the xfs headers has a 64bit off_t type
> */
> extern int xfs_assert_largefile[sizeof(off_t)-8];
>
> Enough of my stream of consciousness, sorry. To summarize the findings:
>
> - we don't really need this patch all
> - but cleaning up xfs_assert_largefile to just use static_assert would
> probably be nice to have anyway
Thanks, I agree, but I think static_assert is C11 (and then it gets a
nicer name in C23). If it's still fine for us, I can then use it.
Does it change your thinking at all or should I send a v4 with it
included?
Thanks,
sam
next prev parent reply other threads:[~2023-12-26 20:50 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-15 1:36 [PATCH v3 1/4] Remove use of LFS64 interfaces Sam James
2023-12-15 1:36 ` [PATCH v3 2/4] io: Assert we have a sensible off_t Sam James
2023-12-19 5:19 ` Darrick J. Wong
2023-12-19 5:54 ` Christoph Hellwig
2023-12-26 20:49 ` Sam James [this message]
2024-01-22 4:58 ` Sam James
2024-01-22 6:33 ` Christoph Hellwig
2024-01-22 7:22 ` Sam James
2023-12-15 1:36 ` [PATCH v3 3/4] build: Request 64-bit time_t where possible Sam James
2023-12-19 5:27 ` Darrick J. Wong
2023-12-15 1:36 ` [PATCH v3 4/4] io: Adapt to >= 64-bit time_t Sam James
2023-12-19 5:27 ` Darrick J. Wong
2023-12-19 5:55 ` [PATCH v3 1/4] Remove use of LFS64 interfaces Christoph Hellwig
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=87v88k1yeq.fsf@gentoo.org \
--to=sam@gentoo.org \
--cc=felix.janda@posteo.de \
--cc=hch@infradead.org \
--cc=linux-xfs@vger.kernel.org \
/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.