lists.openwall.net   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  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Date:	Sun, 7 Jan 2007 23:31:19 +0100
From:	Philippe De Muyter <phdm@...qel.be>
To:	hugh@...itas.com, david-b@...bell.net
Cc:	linux-kernel@...r.kernel.org
Subject: Re: RTC subsystem and fractions of seconds


On Sun, 7 Jan 2007, Hugh Dickins wrote:
> Author: Matt Mackall <mpm@...enic.com>
> 
>     [PATCH] RTC: Remove RTC UIP synchronization on x86
>     
>     Reading the CMOS clock on x86 and some other arches currently takes up to one
>     second because it synchronizes with the CMOS second tick-over.  This delay
>     shows up at boot time as well a resume time.

That is true if kernel's idea of an RTC's precision is 1 second.  With better
RTC's (e.g. m41t81) this delay can be reduced to 0.01 second, which is
acceptable IMHO in the boot phase.  That needs however changes in the kernel
interface to RTC's :

    - read_time should take a new parameter *nsec (or struct rtc_time should
    contain a new nsec field, so that the RTC can report its complete time
    information to the kernel.

    - struct rtc_device (or rtc_class_ops with another name) should contain
    a new field giving the RTC's resolution in nsecs, if we want to avoid the
    loop, but do not want our 0.01 second precision be destructed by always
    adding 0.5 second in rtc_hctosys
    
Philippe
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ