1. 24 3月, 2009 1 次提交
  2. 17 2月, 2009 1 次提交
  3. 16 2月, 2009 1 次提交
    • P
      net: new user space API for time stamping of incoming and outgoing packets · cb9eff09
      Patrick Ohly 提交于
      User space can request hardware and/or software time stamping.
      Reporting of the result(s) via a new control message is enabled
      separately for each field in the message because some of the
      fields may require additional computation and thus cause overhead.
      User space can tell the different kinds of time stamps apart
      and choose what suits its needs.
      
      When a TX timestamp operation is requested, the TX skb will be cloned
      and the clone will be time stamped (in hardware or software) and added
      to the socket error queue of the skb, if the skb has a socket
      associated with it.
      
      The actual TX timestamp will reach userspace as a RX timestamp on the
      cloned packet. If timestamping is requested and no timestamping is
      done in the device driver (potentially this may use hardware
      timestamping), it will be done in software after the device's
      start_hard_xmit routine.
      Signed-off-by: NPatrick Ohly <patrick.ohly@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      cb9eff09
  4. 01 2月, 2009 1 次提交
  5. 27 1月, 2009 1 次提交
  6. 16 1月, 2009 2 次提交
    • H
      avr32: fix out-of-range rjmp instruction on large kernels · 61f3632f
      Haavard Skinnemoen 提交于
      Use .subsection to place fixups closer to their jump targets. This
      increases the maximum size of the kernel before we get link errors
      significantly.
      
      The problem here is that we don't have a "call"-ish pseudo-instruction
      to use instead of rjmp...we could add one, but that means we'll have to
      wait for a new toolchain release, wait until we're fairly sure most
      people are using it, etc...
      
      As an added bonus, it should decrease the RAM footprint slightly,
      though it might pollute the icache a bit more.
      Signed-off-by: NHaavard Skinnemoen <haavard.skinnemoen@atmel.com>
      61f3632f
    • B
      avr32: Fix out-of-range rcalls in large kernels · 8d29b7b9
      Ben Nizette 提交于
      Replace handcoded rcall instructions with the call pseudo-instruction.
      For kernels too far over 1MB the rcall instruction can't reach and
      linking will fail.  We already call the final linker with --relax which
      converts call pseudo-instructions to the right things anyway.
      
      This fixes
      
      arch/avr32/kernel/built-in.o: In function `syscall_exit_work':
      (.ex.text+0x198): relocation truncated to fit: R_AVR32_22H_PCREL against symbol `schedule' defined in .sched.text section in kernel/built-in.o
      arch/avr32/kernel/built-in.o: In function `fault_exit_work':
      (.ex.text+0x3b6): relocation truncated to fit: R_AVR32_22H_PCREL against symbol `schedule' defined in .sched.text section in kernel/built-in.o
      
      But I'm still left with
      
      arch/avr32/kernel/built-in.o:(.fixup+0x2): relocation truncated to fit: R_AVR32_22H_PCREL against `.text'+45a
      arch/avr32/kernel/built-in.o:(.fixup+0x8): relocation truncated to fit: R_AVR32_22H_PCREL against `.text'+8ea
      arch/avr32/kernel/built-in.o:(.fixup+0xe): relocation truncated to fit: R_AVR32_22H_PCREL against `.text'+abe
      arch/avr32/kernel/built-in.o:(.fixup+0x14): relocation truncated to fit: R_AVR32_22H_PCREL against `.text'+ac8
      arch/avr32/kernel/built-in.o:(.fixup+0x1a): relocation truncated to fit: R_AVR32_22H_PCREL against `.text'+ad2
      arch/avr32/kernel/built-in.o:(.fixup+0x20): relocation truncated to fit: R_AVR32_22H_PCREL against `.text'+adc
      arch/avr32/kernel/built-in.o:(.fixup+0x26): relocation truncated to fit: R_AVR32_22H_PCREL against `.text'+ae6
      arch/avr32/kernel/built-in.o:(.fixup+0x2c): relocation truncated to fit: R_AVR32_22H_PCREL against `.text'+af0
      arch/avr32/kernel/built-in.o:(.fixup+0x32): additional relocation overflows omitted from the output
      
      These are caused by a similar problem with 'rjmp' instructions.
      Unfortunately, there's no easy fix for these at the moment since we
      don't have a arbitrary-range 'jmp' instruction similar to 'call'.
      Signed-off-by: NBen Nizette <bn@niasdigital.com>
      Signed-off-by: NHaavard Skinnemoen <haavard.skinnemoen@atmel.com>
      8d29b7b9
  7. 15 1月, 2009 1 次提交
  8. 13 1月, 2009 1 次提交
  9. 07 1月, 2009 7 次提交
  10. 06 1月, 2009 3 次提交
  11. 05 1月, 2009 6 次提交
  12. 01 1月, 2009 2 次提交
  13. 18 12月, 2008 2 次提交
  14. 17 12月, 2008 2 次提交
  15. 13 12月, 2008 1 次提交
  16. 24 10月, 2008 1 次提交
  17. 23 10月, 2008 3 次提交
  18. 20 10月, 2008 2 次提交
    • M
      container freezer: implement freezer cgroup subsystem · dc52ddc0
      Matt Helsley 提交于
      This patch implements a new freezer subsystem in the control groups
      framework.  It provides a way to stop and resume execution of all tasks in
      a cgroup by writing in the cgroup filesystem.
      
      The freezer subsystem in the container filesystem defines a file named
      freezer.state.  Writing "FROZEN" to the state file will freeze all tasks
      in the cgroup.  Subsequently writing "RUNNING" will unfreeze the tasks in
      the cgroup.  Reading will return the current state.
      
      * Examples of usage :
      
         # mkdir /containers/freezer
         # mount -t cgroup -ofreezer freezer  /containers
         # mkdir /containers/0
         # echo $some_pid > /containers/0/tasks
      
      to get status of the freezer subsystem :
      
         # cat /containers/0/freezer.state
         RUNNING
      
      to freeze all tasks in the container :
      
         # echo FROZEN > /containers/0/freezer.state
         # cat /containers/0/freezer.state
         FREEZING
         # cat /containers/0/freezer.state
         FROZEN
      
      to unfreeze all tasks in the container :
      
         # echo RUNNING > /containers/0/freezer.state
         # cat /containers/0/freezer.state
         RUNNING
      
      This is the basic mechanism which should do the right thing for user space
      task in a simple scenario.
      
      It's important to note that freezing can be incomplete.  In that case we
      return EBUSY.  This means that some tasks in the cgroup are busy doing
      something that prevents us from completely freezing the cgroup at this
      time.  After EBUSY, the cgroup will remain partially frozen -- reflected
      by freezer.state reporting "FREEZING" when read.  The state will remain
      "FREEZING" until one of these things happens:
      
      	1) Userspace cancels the freezing operation by writing "RUNNING" to
      		the freezer.state file
      	2) Userspace retries the freezing operation by writing "FROZEN" to
      		the freezer.state file (writing "FREEZING" is not legal
      		and returns EIO)
      	3) The tasks that blocked the cgroup from entering the "FROZEN"
      		state disappear from the cgroup's set of tasks.
      
      [akpm@linux-foundation.org: coding-style fixes]
      [akpm@linux-foundation.org: export thaw_process]
      Signed-off-by: NCedric Le Goater <clg@fr.ibm.com>
      Signed-off-by: NMatt Helsley <matthltc@us.ibm.com>
      Acked-by: NSerge E. Hallyn <serue@us.ibm.com>
      Tested-by: NMatt Helsley <matthltc@us.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      dc52ddc0
    • M
      container freezer: add TIF_FREEZE flag to all architectures · 83224b08
      Matt Helsley 提交于
      This patch series introduces a cgroup subsystem that utilizes the swsusp
      freezer to freeze a group of tasks.  It's immediately useful for batch job
      management scripts.  It should also be useful in the future for
      implementing container checkpoint/restart.
      
      The freezer subsystem in the container filesystem defines a cgroup file
      named freezer.state.  Reading freezer.state will return the current state
      of the cgroup.  Writing "FROZEN" to the state file will freeze all tasks
      in the cgroup.  Subsequently writing "RUNNING" will unfreeze the tasks in
      the cgroup.
      
      * Examples of usage :
      
         # mkdir /containers/freezer
         # mount -t cgroup -ofreezer freezer  /containers
         # mkdir /containers/0
         # echo $some_pid > /containers/0/tasks
      
      to get status of the freezer subsystem :
      
         # cat /containers/0/freezer.state
         RUNNING
      
      to freeze all tasks in the container :
      
         # echo FROZEN > /containers/0/freezer.state
         # cat /containers/0/freezer.state
         FREEZING
         # cat /containers/0/freezer.state
         FROZEN
      
      to unfreeze all tasks in the container :
      
         # echo RUNNING > /containers/0/freezer.state
         # cat /containers/0/freezer.state
         RUNNING
      
      This patch:
      
      The first step in making the refrigerator() available to all
      architectures, even for those without power management.
      
      The purpose of such a change is to be able to use the refrigerator() in a
      new control group subsystem which will implement a control group freezer.
      
      [akpm@linux-foundation.org: fix sparc]
      Signed-off-by: NCedric Le Goater <clg@fr.ibm.com>
      Signed-off-by: NMatt Helsley <matthltc@us.ibm.com>
      Acked-by: NPavel Machek <pavel@suse.cz>
      Acked-by: NSerge E. Hallyn <serue@us.ibm.com>
      Acked-by: NRafael J. Wysocki <rjw@sisk.pl>
      Acked-by: NNigel Cunningham <nigel@tuxonice.net>
      Tested-by: NMatt Helsley <matthltc@us.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      83224b08
  19. 16 10月, 2008 2 次提交