Re: [PATCH 00/61] vfs: change inode->i_ino from unsigned long to u64

Mathieu Desnoyers
2026-02-27T19:01:42Z

On 2026-02-27 12:19, Jeff Layton wrote:
> On Thu, 2026-02-26 at 16:49 +0000, Matthew Wilcox wrote:
>> On Thu, Feb 26, 2026 at 10:55:02AM -0500, Jeff Layton wrote:
>>> The bulk of the changes are to format strings and tracepoints, since the
>>> kernel itself doesn't care that much about the i_ino field. The first
>>> patch changes some vfs function arguments, so check that one out
>>> carefully.
>>
>> Why are the format strings all done as separate patches? Don't we get
>> bisection hazards by splitting it apart this way?
>
> Circling back to this...
>
> I have a v2 series (~107 patches) that I'm testing now that does this
> more bisectably with the typedef and macro scaffolding that Mathieu
> suggested. I'll probably send it early next week.
>
> I had done it this way originally since I figured it was best to break
> this up by subsystem. Should I continue with this series as a set of
> patches broken up this way, or is it preferable to combine the pile of
> format changes into fewer patches?

Here is the approach I would recommend to maximize signal over noise
for the follow up email thread discussions:

Now that your series is bisectable, you could post a [RFC PATCH v2]
series with the following:

- Patch 00 introduces the series, points to your git branch implementing
the whole series,
- The first few patches introduce the new type (kino_t) and macro to
do the format string transition. Initially kino_t would typedef to
unsigned long (no changes).
- Followed by patches implementing the type + format string changes for
a few key subsystems.
- The final patch would change kino_t and the format string macro to
64-bit integers.

Once everyone agree on those core changes, you could proceed to post
patches that change additional subsystems in a subsequent round.

One more comment: have you tried using Coccinelle to do this kind of
semantic code change ?

Thanks,

Mathieu

--
Mathieu Desnoyers
EfficiOS Inc.