> This version now looks ok to me. > > I do have a comment (or maybe just a RFD) for future work. > > It does strike me that once we actually change over the inode times to > use timespec64, the calling conventions are going to be fairly > horrendous on most 32-bit architectures. > > Gcc handles 8-byte structure returns (on most architectures) by > returning them as two 32-bit registers (%edx:%eax on x86). But once it > is timespec64, that will no longer be the case, and the calling > convention will end up using a pointer to the local stack instead. > > So for 32-bit code generation, we *may* want to introduce a new model of doing > > set_inode_time(inode, ATTR_ATIME | ATTR_MTIME); > > which basically just does > > inode->i_atime = inode->i_mtime = current_time(inode); > > but with a much easier calling convention on 32-bit architectures. Arnd and I had discussed something like this before. But, for entirely different reasons: Having the set_inode_time() like you suggest will also help switching of vfs inode times to timespec64. We were suggesting all the accesses to inode time be abstracted through something like inode_set_time(). Arnd also had suggested a split representation of fields in the struct inode as well which led to space savings as well. And, having the split representation also meant no more direct assignments: https://lkml.org/lkml/2016/1/7/20 This in general will be similar to setattr_copy(), but only sets times rather than other attributes as well. If this is what is preferred, then the patches to change vfs to use timespec64 could make use of this and will need to be refactored. So maybe it would be good to discuss before I post those patches. -Deepa -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
