lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 16 Jul 2010 22:51:30 -0700
From:	Mark Harris <>
To:	David Howells <>
Cc:	Arnd Bergmann <>, Steve French <>,,,,,,,
Subject: Re: [PATCH 02/18] xstat: Add a pair of system calls to make
	extended file stats available [ver #6]

David Howells wrote:
> With a 2:2 split between exponent
> (tv_gran_units) and mantissa (tv_granularity), you can do:
> 	nanoseconds	0.000000001	-9		1
> 	microseconds	0.000001	-6		1
> 	millseconds	0.001		-3		1
> 	seconds		1		0		1
> 	minutes		60		1		6
> 	hours		3600		2		36
> 	days		86400		2		864
> 	weeks		604800		2		6048

At least for the in-tree filesystems, I do not see any that keep
timestamps with a granularity larger than 2s.  For that, a simple
32-bit tv_granularity in nanoseconds (not limited to 1e9) would
suffice, and there is no need for the complexity of dealing with
a separate exponent.

If there is a need to handle larger granularity, its msb could
potentially be used to indicate that the number is in seconds
instead of nanoseconds.  This is convenient because the timestamp
is already broken down into sec and nsec fields.  So this bit would
then indicate that the granularity applies to the tv_sec field, and
that tv_nsec is not in use.  But even this is overkill if no one
uses a granularity larger than 2s.

 - Mark
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists