similar to: [LLVMdev] File timestamps

Displaying 20 results from an estimated 200000 matches similar to: "[LLVMdev] File timestamps"

2014 Sep 22
0
Re: [PATCH] New APIs: Implement stat calls that return nanosecond timestamps (RHBZ#1144891).
On Monday 22 September 2014 13:48:38 Richard W.M. Jones wrote: > The existing APIs guestfs_stat, guestfs_lstat and guestfs_lstatlist > return a stat structure that contains atime, mtime and ctime fields > that store only the timestamp in seconds. > > Modern filesystems can store timestamps down to nanosecond > granularity, and the ordinary glibc stat(2) wrapper will return these
2010 Jul 08
1
Query about using timestamps returned by SQL as 'factor' for split
I have a simple query as follows: "SELECT m_id,sale_date,YEAR(sale_date),WEEK(sale_date),return_type,DATEDIFF(return_date,sale_date) AS elapsed_time FROM risk_input" I can get, and view, all the data that that query returns. The question is, sale_date is a timestamp, and I need to call split to group this data by m_id and the week in which the sale occurred. Obviously, I would
2020 Jan 10
0
[PATCH 09/23] drm: Remove struct drm_driver.get_scanout_position()
All users of struct drm_driver.get_scanout_position() have been covnerted to the respective CRTC helper function. Remove the callback from struct drm_driver. Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de> --- drivers/gpu/drm/drm_vblank.c | 13 ++------- include/drm/drm_drv.h | 52 ------------------------------------ 2 files changed, 2 insertions(+), 63 deletions(-) diff
2020 Jan 10
0
[PATCH 01/23] drm: Add get_scanout_position() to struct drm_crtc_helper_funcs
The new callback get_scanout_position() reads the current location of the scanout process. The operation is currentyl located in struct drm_driver, but really belongs to the CRTC. Drivers will be converted in separate patches. Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de> --- drivers/gpu/drm/drm_vblank.c | 24 ++++++++---- include/drm/drm_drv.h |
2020 Jan 10
0
[PATCH 01/23] drm: Add get_scanout_position() to struct drm_crtc_helper_funcs
On Fri, 10 Jan 2020, Thomas Zimmermann <tzimmermann at suse.de> wrote: > The new callback get_scanout_position() reads the current location of > the scanout process. The operation is currentyl located in struct > drm_driver, but really belongs to the CRTC. Drivers will be converted > in separate patches. > > Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de>
2011 Mar 07
0
[LLVMdev] llvm.gcroot suggestion
On Mon, Mar 7, 2011 at 9:35 AM, Talin <viridia at gmail.com> wrote: > On Mon, Mar 7, 2011 at 4:08 AM, nicolas geoffray < > nicolas.geoffray at gmail.com> wrote: > >> Hi Talin, >> >> On Sat, Mar 5, 2011 at 6:42 PM, Talin <viridia at gmail.com> wrote: >>> >>> >>> So I've been thinking about your proposal, that of using a
2020 Jan 10
0
[PATCH 03/23] drm/i915: Don't use struct drm_driver.get_scanout_position()
The callback struct drm_driver.get_scanout_position() is deprecated in favor of struct drm_crtc_helper_funcs.get_scanout_position(). i915 doesn't use CRTC helpers. The patch duplicates the caller drm_calc_vbltimestamp_from_scanoutpos() for i915, such that the callback function is not needed. Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de> --- drivers/gpu/drm/i915/i915_drv.c
2020 Jan 14
1
[PATCH 01/23] drm: Add get_scanout_position() to struct drm_crtc_helper_funcs
Thanks for the patch. Tested-by: Yannick Fertr? <yannick.fertre at st.com><mailto:yannick.fertre at st.com> BR Yannick Fertr? On 1/10/20 10:21 AM, Thomas Zimmermann wrote: The new callback get_scanout_position() reads the current location of the scanout process. The operation is currentyl located in struct drm_driver, but really belongs to the CRTC. Drivers will be converted in
2020 Jan 20
0
[PATCH v3 02/22] drm: Add get_scanout_position() to struct drm_crtc_helper_funcs
The new callback get_scanout_position() reads the current location of the scanout process. The operation is currently located in struct drm_driver, but really belongs to the CRTC. Drivers will be converted in separate patches. To help with the conversion, the timestamp calculation has been moved from drm_calc_vbltimestamp_from_scanoutpos() to
2020 Jan 23
0
[PATCH v4 02/22] drm: Add get_scanout_position() to struct drm_crtc_helper_funcs
The new callback get_scanout_position() reads the current location of the scanout process. The operation is currently located in struct drm_driver, but really belongs to the CRTC. Drivers will be converted in separate patches. To help with the conversion, the timestamp calculation has been moved from drm_calc_vbltimestamp_from_scanoutpos() to
2020 Jan 10
1
[PATCH 03/23] drm/i915: Don't use struct drm_driver.get_scanout_position()
On Fri, 10 Jan 2020, Thomas Zimmermann <tzimmermann at suse.de> wrote: > Hi > > Am 10.01.20 um 12:59 schrieb Jani Nikula: >> On Fri, 10 Jan 2020, Thomas Zimmermann <tzimmermann at suse.de> wrote: >>> The callback struct drm_driver.get_scanout_position() is deprecated in >>> favor of struct drm_crtc_helper_funcs.get_scanout_position(). >>>
2020 Jan 10
0
[PATCH 23/23] drm: Cleanup VBLANK callbacks in struct drm_driver
All non-legacy users of VBLANK functions in struct drm_driver have been converted to use the respective interfaces in struct drm_crtc_funcs. The remaining users of VBLANK callbacks in struct drm_driver are legacy drivers with userspace modesetting. There are no users left of get_vblank_timestamp(), so the callback is being removed. The other VBLANK callbacks are being moved to the legacy section
2011 Mar 07
2
[LLVMdev] llvm.gcroot suggestion
On Mon, Mar 7, 2011 at 4:08 AM, nicolas geoffray <nicolas.geoffray at gmail.com > wrote: > Hi Talin, > > On Sat, Mar 5, 2011 at 6:42 PM, Talin <viridia at gmail.com> wrote: >> >> >> So I've been thinking about your proposal, that of using a special address >> space to indicate garbage collection roots instead of intrinsics. > > > Great!
2000 Mar 10
0
2.0.6: file timestamps acting strange - even with patch.
> I'm running samba 2.X on Solaris (2.6, 2.5.1), and SunOS 4.X (but don't > tell anyone about that last one). > > I had been running samba 2.0.3, and one of my users noticed that when he > copied a file, using an NT 4.0 workstation, copying a file from an NT > fileserver (NTFS) to a Samba filesystem, that the dates were wrong on > the copied file. In particular, any
2011 Mar 07
0
[LLVMdev] llvm.gcroot suggestion
Hi Talin, On Sat, Mar 5, 2011 at 6:42 PM, Talin <viridia at gmail.com> wrote: > > > So I've been thinking about your proposal, that of using a special address > space to indicate garbage collection roots instead of intrinsics. Great! > > To address this, we need a better way of telling LLVM that a given variable > is no longer a root. > Live variable
2002 Oct 16
2
HELP !!! Problem with file timestamps updating "weird" during rsync data pull
Running rsync 2.3.1, 2.4.1, and 2.5.5 on Solaris 8 on various system. I'm using rsync to pull data over for collecting performance data for graphing in Orca. What I'm seeing is the timestamps from time to time of the data files is being setup "weird" on the system the data is being pulled to. The timestamp should match that of the system the data is pulled from right ?
2020 Jan 10
0
[PATCH 03/23] drm/i915: Don't use struct drm_driver.get_scanout_position()
Hi Am 10.01.20 um 12:59 schrieb Jani Nikula: > On Fri, 10 Jan 2020, Thomas Zimmermann <tzimmermann at suse.de> wrote: >> The callback struct drm_driver.get_scanout_position() is deprecated in >> favor of struct drm_crtc_helper_funcs.get_scanout_position(). >> >> i915 doesn't use CRTC helpers. The patch duplicates the caller >>
2015 Sep 14
3
[Bug 11521] New: rsync does not use high-resolution timestamps to determine file differences
https://bugzilla.samba.org/show_bug.cgi?id=11521 Bug ID: 11521 Summary: rsync does not use high-resolution timestamps to determine file differences Product: rsync Version: 3.1.2 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 Component: core
1998 Aug 25
1
NT timestamps; WINS lookup
Two questions. First, timestamps seem to be getting screwed up when I access files on the company's NT server. Someone (using NT) creates some files. My ls -l output shows them as having screwed up dates (ie, 1935, 2027, etc). 95, 98, and NT users see the dates as normal. When I copy any files with cp, the dates change for me, although remain nonsensical, but now the timestamp is also
2007 Oct 05
0
file type to monitor files recursively and ignore dir timestamps
I have a manifest that looks for changes in files recursively and restarts a service should it find any changes. Problem is that i ''ignore'' some files that i do not wish to monitor and ones that change occasionally and when they change it modifies the timestamp on the directory which in turn triggers puppet to restart the service. So is there a way to monitor only file