1. 09 Sep, 2021 1 commit
    • Florian Bezdeka's avatar
      lib/boilerplate/iniparser: Allow building with GCC 10.2 2020101 · efb12a1d
      Florian Bezdeka authored and Jan Kiszka's avatar Jan Kiszka committed
      Updating to upstream revision f858275f7f307eecba84c2f5429483f9f28007f8.
      Upstream repository is located at [1].
      
      The reason for updating was the following compiler error when trying
      to compile with GCC 10.2 10.2.1 20201016. As it turned out the problem
      was already addressed upstream:
      
      iniparser/iniparser.c: In function ‘iniparser_load’:
      iniparser/iniparser.c:616:13: error: ‘sprintf’ arguments 3, 4 may
      overlap destination object ‘buf’ [-Werror=restrict]
         616 |             sprintf(tmp, "%s:%s", section, key);
             |             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      
      I reviewed especially the API changes. Most of them are cleanups only
      but two things should be pointed out:
      
        - The type of the size field of struct _dictionary_ changed from int
          to ssize_t. The only user of this struct is
          lib/analogy/calibration.c which uses this structure for internal
          things only. It is never exposed to any public API so updating is
          OK and fully backward compatible.
      
        - dictionary_new changed its signature
            from dictionary_new(int size)
            to   dictionary_new(size_t size).
          This function is not part of any public API. So updating does not
          break backward compatibility.
      
      [1] https://github.com/ndevilla/iniparser
      
      Signed-off-by: default avatarFlorian Bezdeka <florian.bezdeka@siemens.com>
      Signed-off-by: Jan Kiszka's avatarJan Kiszka <jan.kiszka@siemens.com>
      efb12a1d
  2. 07 Jul, 2021 1 commit
  3. 25 May, 2021 1 commit
    • Philippe Gerum's avatar
      cobalt/vfile: seq_file seek index must progress · 65a608ec
      Philippe Gerum authored and Jan Kiszka's avatar Jan Kiszka committed
      
      
      The offset field we receive from the kernel in a vfile next() handler
      must progress in order for the loop to stop properly, independently
      from our own tracking of the end-of-list condition.
      
      Bug is reproducible by running two loops in parallel:
      
      - one continuously spawning an application which creates a few tenths
      of threads (10-20 would suffice) before exiting shortly after.
      
      - another one continuously reading from /proc/xenomai/sched/{threads,
        stat, acct}.
      
      At some point, the vfile handler should cause a kernel crash.
      Signed-off-by: Philippe Gerum's avatarPhilippe Gerum <rpm@xenomai.org>
      Signed-off-by: Jan Kiszka's avatarJan Kiszka <jan.kiszka@siemens.com>
      65a608ec
  4. 14 May, 2021 1 commit
  5. 09 Nov, 2020 1 commit
  6. 13 Oct, 2020 4 commits
  7. 14 Feb, 2020 1 commit
  8. 07 Feb, 2020 1 commit
  9. 05 Feb, 2020 13 commits
  10. 19 Dec, 2019 3 commits
  11. 09 Dec, 2019 1 commit
  12. 06 Dec, 2019 1 commit
    • Jan Kiszka's avatar
      ci: Do not stumble over annotated ipipe tags · 8a1e7b6c
      Jan Kiszka authored
      
      
      Currently not an issue for the kernels we pull here, but 4.14-ppc would
      break e.g. because ls-remote --tags gives
      
      ... ipipe-core-4.14.36-ppc32-1.1
      ... ipipe-core-4.14.36-ppc32-1.1^{}
      
      with the second one representing the dereferentiation of the annotated
      tag. We only need the first one, though, while the second breaks git
      clone. --refs filters this.
      Signed-off-by: Jan Kiszka's avatarJan Kiszka <jan.kiszka@siemens.com>
      8a1e7b6c
  13. 03 Dec, 2019 8 commits
  14. 04 Nov, 2019 3 commits