On 9/4/23, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > On Sun, 3 Sept 2023 at 20:07, Linus Torvalds > <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: >> >> Try it and you'll see it is not even *remotely* as easy as you claim. >> Not when you have to deal with random sizes and padding of 20+ >> different architectures. > > Perhaps more importantly, nobody actually seems to have the energy to care. > Perhaps in this context I should have explicitly mentioned that only 64-bit archs would be considered, as in placing the func you wrote in fs/stat.c and it is explicitly 64-bit. This should whack all archs which would never bother with their implementation anyway. Worst case if the 64 bit structs differ one can settle for user-accessing INIT_STRUCT_STAT_PADDING. My point though was that code filling the struct escaping to arch-dependent file is rather regrettable, even if x86-64 would be the only case. And it definitely can be avoided, even if would require tolerating that some of the stores are reordered. They are already reordered for dodging memset. -- Mateusz Guzik <mjguzik gmail.com>