Theodore Tso wrote: > On Mon, Aug 18, 2008 at 10:08:11AM +0800, Li Zefan wrote: >>> I'm worried about writing a struct timespec directly to user space, >>> because the kernel's idea of what is struct timespec might not be the >>> same as the userspace's understanding of struct timespec --- >> We have system call nanosleep(), which copies a struct timespec directly >> from user space. > > The difference is that for system calls, we have a glue layer (glibc) > whose duties include translating between the kernel data structures > and the userpsace data structures --- and for various architectures > there are ***no*** guarantees that the interfaces shipped by glibc in > /usr/include match up with the data structures used by the kernel in > /usr/src/linux/include/linux. > > When you use an ioctl, you bypass the glibc translation layer, so life > can get iffy here. And given that struct timespec contains time_t, > which *can* differ from architecture to architecure in in terms of > being either 32 bits or 64 bits, and what is in the kernel might be > different from what is in the user space /usr/include, I get doubly > nervous. > I got the point, thanks. :) >>> I think we would be better off explicitly defining a structure, or >>> just returning the seconds and nanoseconds in explicit primitive >>> types. > > That's the quick and dirty fast answer, yes. The long-term (but one > which involves much more work) is to define a new struct > kernel<->glibc stat interface (we already have 5 or so :-) to extend > it include st_crtime, and then try to get glibc to use the magic of > ELF symbol versioning so there is a new struct stat as defined in > /usr/include, and a new stat(2) call defined in glibc, which returns > the new struct stat which include st_crtime. This also means we have > to define proper semantics for what happens if a filesystem doesn't > support st_crtime. > Yes, my first thought was if stat can report crtime. So, for now I think we can use timespec_to_ns() to convert the time to a s64 value and return it to the userspace. -- 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
