Re: [PATCH 1/3] ext4: add EXT4_IOC_GETCRTIME ioctl

[Li Zefan <lizf@cn.fujitsu.com>]

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.