1. 14 1月, 2020 1 次提交
    • A
      ns: Introduce Time Namespace · 769071ac
      Andrei Vagin 提交于
      Time Namespace isolates clock values.
      
      The kernel provides access to several clocks CLOCK_REALTIME,
      CLOCK_MONOTONIC, CLOCK_BOOTTIME, etc.
      
      CLOCK_REALTIME
            System-wide clock that measures real (i.e., wall-clock) time.
      
      CLOCK_MONOTONIC
            Clock that cannot be set and represents monotonic time since
            some unspecified starting point.
      
      CLOCK_BOOTTIME
            Identical to CLOCK_MONOTONIC, except it also includes any time
            that the system is suspended.
      
      For many users, the time namespace means the ability to changes date and
      time in a container (CLOCK_REALTIME). Providing per namespace notions of
      CLOCK_REALTIME would be complex with a massive overhead, but has a dubious
      value.
      
      But in the context of checkpoint/restore functionality, monotonic and
      boottime clocks become interesting. Both clocks are monotonic with
      unspecified starting points. These clocks are widely used to measure time
      slices and set timers. After restoring or migrating processes, it has to be
      guaranteed that they never go backward. In an ideal case, the behavior of
      these clocks should be the same as for a case when a whole system is
      suspended. All this means that it is required to set CLOCK_MONOTONIC and
      CLOCK_BOOTTIME clocks, which can be achieved by adding per-namespace
      offsets for clocks.
      
      A time namespace is similar to a pid namespace in the way how it is
      created: unshare(CLONE_NEWTIME) system call creates a new time namespace,
      but doesn't set it to the current process. Then all children of the process
      will be born in the new time namespace, or a process can use the setns()
      system call to join a namespace.
      
      This scheme allows setting clock offsets for a namespace, before any
      processes appear in it.
      
      All available clone flags have been used, so CLONE_NEWTIME uses the highest
      bit of CSIGNAL. It means that it can be used only with the unshare() and
      the clone3() system calls.
      
      [ tglx: Adjusted paragraph about clone3() to reality and massaged the
        	changelog a bit. ]
      Co-developed-by: NDmitry Safonov <dima@arista.com>
      Signed-off-by: NAndrei Vagin <avagin@gmail.com>
      Signed-off-by: NDmitry Safonov <dima@arista.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Link: https://criu.org/Time_namespace
      Link: https://lists.openvz.org/pipermail/criu/2018-June/041504.html
      Link: https://lore.kernel.org/r/20191112012724.250792-4-dima@arista.com
      
      769071ac
  2. 05 1月, 2020 1 次提交
    • P
      Documentation: riscv: add patch acceptance guidelines · 0e194d9d
      Paul Walmsley 提交于
      Formalize, in kernel documentation, the patch acceptance policy for
      arch/riscv.  In summary, it states that as maintainers, we plan to
      only accept patches for new modules or extensions that have been
      frozen or ratified by the RISC-V Foundation.
      
      We've been following these guidelines for the past few months.  In the
      meantime, we've received quite a bit of feedback that it would be
      helpful to have these guidelines formally documented.
      
      Based on a suggestion from Matthew Wilcox, we also add a link to this
      file to Documentation/process/index.rst, to make this document easier
      to find.  The format of this document has also been changed to align
      to the format outlined in the maintainer entry profiles, in accordance
      with comments from Jon Corbet and Dan Williams.
      Signed-off-by: NPaul Walmsley <paul.walmsley@sifive.com>
      Reviewed-by: NPalmer Dabbelt <palmerdabbelt@google.com>
      Cc: Palmer Dabbelt <palmer@dabbelt.com>
      Cc: Albert Ou <aou@eecs.berkeley.edu>
      Cc: Krste Asanovic <krste@berkeley.edu>
      Cc: Andrew Waterman <waterman@eecs.berkeley.edu>
      Cc: Matthew Wilcox <willy@infradead.org>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Jonathan Corbet <corbet@lwn.net>
      0e194d9d
  3. 26 12月, 2019 1 次提交
  4. 22 12月, 2019 2 次提交
  5. 20 12月, 2019 1 次提交
    • C
      riscv: move sifive_l2_cache.c to drivers/soc · 9209fb51
      Christoph Hellwig 提交于
      The sifive_l2_cache.c is in no way related to RISC-V architecture
      memory management.  It is a little stub driver working around the fact
      that the EDAC maintainers prefer their drivers to be structured in a
      certain way that doesn't fit the SiFive SOCs.
      
      Move the file to drivers/soc and add a Kconfig option for it, as well
      as the whole drivers/soc boilerplate for CONFIG_SOC_SIFIVE.
      
      Fixes: a967a289 ("RISC-V: sifive_l2_cache: Add L2 cache controller driver for SiFive SoCs")
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Reviewed-by: NBorislav Petkov <bp@suse.de>
      [paul.walmsley@sifive.com: keep the MAINTAINERS change specific to the L2$ controller code]
      Signed-off-by: NPaul Walmsley <paul.walmsley@sifive.com>
      9209fb51
  6. 14 12月, 2019 1 次提交
  7. 11 12月, 2019 1 次提交
  8. 10 12月, 2019 4 次提交
  9. 08 12月, 2019 2 次提交
  10. 07 12月, 2019 3 次提交
  11. 06 12月, 2019 2 次提交
  12. 03 12月, 2019 2 次提交
  13. 01 12月, 2019 1 次提交
  14. 27 11月, 2019 5 次提交
  15. 26 11月, 2019 2 次提交
  16. 25 11月, 2019 4 次提交
  17. 23 11月, 2019 3 次提交
  18. 22 11月, 2019 4 次提交
新手
引导
客服 返回
顶部