1. 15 11月, 2014 1 次提交
  2. 25 7月, 2014 1 次提交
  3. 01 6月, 2014 1 次提交
    • L
      util: fix DST end date in virtimetest timezones · 83c41ceb
      Laine Stump 提交于
      Reported by: Roman Bogorodskiy <bogorodskiy@gmail.com>
      
      Some of the tests for virTimeLocalOffsetFromUTC set an imaginary
      timezone that attempts to force dyalight savings time active all the
      time by setting a start date of 0/00:00:00 and end date of
      366/23:59:59. Since the day is 0-based, 366 really means "day 367"
      which will never occur - this was an attempt to eliminate problems
      with DST not being active in some cases right around midnight on
      January 1. Even though it didn't completely solve the problem, it
      didn't seem to cause harm so it was left in the test timezones.
      
      Although Linux glibc doesn't mind having a DST end date of 366,
      FreeBSD refuses to use such timezones, so the tests fail. This patch
      changes the 366 to 365.
      
      This may or may not cause failure of the remaining DST tests around
      midnight Jan 1. If so, we will need to disable those tests at year's
      end too.
      83c41ceb
  4. 29 5月, 2014 1 次提交
    • L
      util: fix virTimeLocalOffsetFromUTC DST processing · 26d43113
      Laine Stump 提交于
      The original version of virTimeLocalOffsetFromUTC() would fail for
      certain times of the day if daylight savings time was active. This
      could most easily be seen by uncommenting the TEST_LOCALOFFSET() cases
      that include a DST setting.
      
      After a lot of experimenting, I found that the way to solve it in
      almost all test cases is to set tm_isdst = -1 in the struct tm prior
      to calling mktime(). Once this is done, the correct offset is returned
      for all test cases at all times except the two hours just after
      00:00:00 Jan 1 UTC - during that time, any timezone that is *behind*
      UTC, and that is supposed to always be in DST will not have DST
      accounted for in its offset.
      
      I believe that the code of virTimeLocalOffsetFromUTC() actually is
      correct for all cases, but the problem still encountered is due to our
      inability to come up with a TZ string that properly forces DST to
      *always* be active. Since a modfication of the (currently fixed)
      expected result data to account for this would necessarily use the
      same functions that we're trying to test, I've instead just made the
      test program conditionally bypass the problematic cases if the current
      date is either December 31 or January 1. This way we get maximum
      testing during 363 days of the year, but don't get false failures on
      Dec 31 and Jan 1.
      26d43113
  5. 26 5月, 2014 1 次提交
    • L
      util: new function virTimeLocalOffsetFromUTC · 1cddaea7
      Laine Stump 提交于
      Since there isn't a single libc API to get this value, this patch
      supplies one which gets the value by grabbing current time, then
      converting that into a struct tm with gmtime_r(), then back to a
      time_t using mktime.
      
      The returned value is the difference between UTC and localtime in
      seconds. If localtime is ahead of UTC (east) the offset will be a
      positive number, and if localtime is behind UTC (west) the offset will
      be negative.
      
      This function should be POSIX-compliant, and is threadsafe, but not
      async signal safe. If it was ever necessary to know this value in a
      child process, we could cache it with a one-time init function when
      libvirtd starts, then just supply the cached value, but that
      complexity isn't needed for current usage; that would also have the
      problem that it might not be accurate after a local daylight savings
      boundary.
      
      (If it weren't for DST, we could simply replace this entire function
      with "-timezone"; timezone contains the offset of the current timezone
      (negated from what we want) but doesn't account for DST. And in spite
      of being guaranteed by POSIX, it isn't available on older versions of
      mingw.)
      Signed-off-by: NEric Blake <eblake@redhat.com>
      1cddaea7
  6. 18 3月, 2014 2 次提交
  7. 08 10月, 2013 1 次提交
  8. 02 5月, 2013 1 次提交
    • M
      virutil: Move string related functions to virstring.c · 7c9a2d88
      Michal Privoznik 提交于
      The source code base needs to be adapted as well. Some files
      include virutil.h just for the string related functions (here,
      the include is substituted to match the new file), some include
      virutil.h without any need (here, the include is removed), and
      some require both.
      7c9a2d88
  9. 21 12月, 2012 4 次提交
  10. 02 11月, 2012 1 次提交
  11. 21 9月, 2012 1 次提交
  12. 23 7月, 2012 1 次提交
    • O
      Desert the FSF address in copyright · f9ce7dad
      Osier Yang 提交于
      Per the FSF address could be changed from time to time, and GNU
      recommends the following now: (http://www.gnu.org/licenses/gpl-howto.html)
      
        You should have received a copy of the GNU General Public License
        along with Foobar.  If not, see <http://www.gnu.org/licenses/>.
      
      This patch removes the explicit FSF address, and uses above instead
      (of course, with inserting 'Lesser' before 'General').
      
      Except a bunch of files for security driver, all others are changed
      automatically, the copyright for securify files are not complete,
      that's why to do it manually:
      
        src/security/security_selinux.h
        src/security/security_driver.h
        src/security/security_selinux.c
        src/security/security_apparmor.h
        src/security/security_apparmor.c
        src/security/security_driver.c
      f9ce7dad
  13. 27 3月, 2012 1 次提交
    • M
      Cleanup for a return statement in source files · 9943276f
      Martin Kletzander 提交于
      Return statements with parameter enclosed in parentheses were modified
      and parentheses were removed. The whole change was scripted, here is how:
      
      List of files was obtained using this command:
      git grep -l -e '\<return\s*([^()]*\(([^()]*)[^()]*\)*)\s*;' |             \
      grep -e '\.[ch]$' -e '\.py$'
      
      Found files were modified with this command:
      sed -i -e                                                                 \
      's_^\(.*\<return\)\s*(\(\([^()]*([^()]*)[^()]*\)*\))\s*\(;.*$\)_\1 \2\4_' \
      -e 's_^\(.*\<return\)\s*(\([^()]*\))\s*\(;.*$\)_\1 \2\3_'
      
      Then checked for nonsense.
      
      The whole command looks like this:
      git grep -l -e '\<return\s*([^()]*\(([^()]*)[^()]*\)*)\s*;' |             \
      grep -e '\.[ch]$' -e '\.py$' | xargs sed -i -e                            \
      's_^\(.*\<return\)\s*(\(\([^()]*([^()]*)[^()]*\)*\))\s*\(;.*$\)_\1 \2\4_' \
      -e 's_^\(.*\<return\)\s*(\([^()]*\))\s*\(;.*$\)_\1 \2\3_'
      9943276f
  14. 30 11月, 2011 1 次提交
    • D
      Add internal APIs for dealing with time · 3ec12898
      Daniel P. Berrange 提交于
      The logging APIs need to be able to generate formatted timestamps
      using only async signal safe functions. This rules out using
      gmtime/localtime/malloc/gettimeday(!) and much more.
      
      Introduce a new internal API which is async signal safe.
      
        virTimeMillisNowRaw replacement for gettimeofday. Uses clock_gettime
                            where available, otherwise falls back to the unsafe
                            gettimeofday
      
        virTimeFieldsNowRaw  replacements for gmtime(), convert a timestamp
        virTimeFieldsThenRaw into a broken out set of fields. No localtime()
                             replacement is provided, because converting to
                             local time is not practical with only async signal
                             safe APIs.
      
        virTimeStringNowRaw  replacements for strftime() which print a timestamp
        virTimeStringThenRaw into a string, using a pre-determined format, with
                             a fixed size buffer (VIR_TIME_STRING_BUFLEN)
      
      For each of these there is also a version without the Raw postfix
      which raises a full libvirt error. These versions are not async
      signal safe
      
      * src/Makefile.am, src/util/virtime.c, src/util/virtime.h: New files
      * src/libvirt_private.syms: New APis
      * configure.ac: Check for clock_gettime in -lrt
      * tests/virtimetest.c, tests/Makefile.am: Test new APIs
      3ec12898