On Fri, Mar 28, 2025 at 12:18:16PM +1100, NeilBrown wrote: > On Fri, 21 Mar 2025, David Howells wrote: > > NeilBrown <neil@xxxxxxxxxx> wrote: > > > > > Also the path component name is passed as "name" and "len" which are > > > (confusingly?) separate by the "base". In some cases the len in simply > > > "strlen" and so passing a qstr using QSTR() would make the calling > > > clearer. > > > Other callers do pass separate name and len which are stored in a > > > struct. Sometimes these are already stored in a qstr, other times it > > > easily could be. > > > > > > So this patch changes these three functions to receive a 'struct qstr', > > > and improves the documentation. > > > > You did want 'struct qstr' not 'struct qstr *' right? I think there are > > arches where this will cause the compiler to skip a register argument or two > > if it's the second argument or third argument - i386 for example. Plus you > > have an 8-byte alignment requirement because of the u64 in it that may suck if > > passed through several layers of function. > > I don't think it is passed through several layers - except where the > intermediate are inlined. > And gcc enforces 16 byte alignment of the stack on function calls for > i386, so I don't think alignment will be an issue. > > I thought 'struct qstr' would result in slightly cleaner calling. But I > cannot make a strong argument in favour of it so I'm willing to change > if there are concerns. Fwiw, I massaged the whole series to pass struct qstr * instead of struct qstr. I just forgot to finish that rebase and push. /me doing so now.
