On 06/02/2014 12:19 PM, Arnd Bergmann wrote: > On Monday 02 June 2014 13:52:19 Joseph S. Myers wrote: >> On Fri, 30 May 2014, Arnd Bergmann wrote: >> >>> a) is this the right approach in general? The previous discussion >>> pointed this way, but there may be other opinions. >> >> The syscall changes seem like the sort of thing I'd expect, although >> patches adding new syscalls or otherwise affecting the kernel/userspace >> interface (as opposed to those relating to an individual filesystem) >> should go to linux-api as well as other relevant lists. > > Ok. Sorry about missing linux-api, I confused it with linux-arch, which > may not be as relevant here, except for the one question whether we > actually want to have the new ABI on all 32-bit architectures or only > as an opt-in for those that expect to stay around for another 24 years. > > Two more questions for you: > > - are you (and others) happy with adding this type of stat syscall > (fstatat64/fstat64) as opposed to the more generic xstat that has > been discussed in the past and that never made it through the bike- > shedding discussion? > > - once we have enough buy-in from reviewers to merge this initial > series, should we proceed to define rest of the syscall ABI > (minus driver ioctls) so glibc and kernel can do the conversion > on top of that, or should we better try to do things one syscall > family at a time and actually get the kernel to handle them > correctly internally? > The bit that is really going to hurt is every single ioctl that uses a timespec. Honestly, though, I really don't understand the point with "struct inode_time". It seems like the zeroeth-order thing is to change the kernel internal version of struct timespec to have a 64-bit time... it isn't just about inodes. We then should be explicit about the external uses of time, and use accessors. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html