1. 08 Nov, 2011 6 commits
  2. 17 Oct, 2011 1 commit
    • Greg Ungerer's avatar
      m68k: reorganize Kconfig options to improve mmu/non-mmu selections · 0e152d80
      Greg Ungerer authored
      The current mmu and non-mmu Kconfig files can be merged to form
      a more general selection of options. The current break up of options
      is due to the simple brute force merge from the m68k and m68knommu
      arch directories.
      
      Many of the options are not at all specific to having the MMU enabled
      or not. They are actually associated with a particular CPU type or
      platform type.
      
      Ultimately as we support all processors with the MMU disabled we need
      many of these options to be selectable without the MMU option enabled.
      And likewise some of the ColdFire processors, which currently are only
      supported with the MMU disabled, do have MMU hardware, and will need
      to have options selected on CPU type, not MMU disabled.
      
      This patch removes the old mmu and non-mmu Kconfigs and instead breaks
      up the configuration into four areas: cpu, machine, bus, devices.
      
      The Kconfig.cpu lists all the options associated with selecting a CPU,
      and includes options specific to each CPU type as well.
      
      Kconfig.machine lists all options associated with selecting a machine
      type. Almost always the machines selectable is restricted by the chosen
      CPU.
      
      Kconfig.bus contains options associated with selecting bus types on the
      various machine types. That includes PCI bus, PCMCIA bus, etc.
      
      Kconfig.devices contains options for drivers and driver associated
      options.
      Signed-off-by: default avatarGreg Ungerer <gerg@uclinux.org>
      0e152d80
  3. 03 Aug, 2011 1 commit
  4. 24 Jul, 2011 1 commit
    • Greg Ungerer's avatar
      m68k: merge mmu and non-mmu bitops.h · 171d809d
      Greg Ungerer authored
      The following patch merges the mmu and non-mmu versions of the m68k
      bitops.h files. Now there is a good deal of difference between the two
      files, but none of it is actually an mmu specific difference. It is
      all about the specific m68k/coldfire varient we are targeting. So it
      makes an awful lot of sense to merge these into a single bitops.h.
      
      There is a number of ways I can see to factor this code. The approach
      I have taken here is to keep the various versions of each macro/function
      type together. This means that there is some ifdefery with each to handle
      each CPU type.
      
      I have added some comments in a couple of appropriate places to try
      and make it clear what the differences we are dealing with are.
      Specifically the instruction and addressing mode differences we have
      to deal with.
      
      The merged form keeps the same underlying optimizations for each CPU
      type for all the general bit clear/set/change and find bit operations.
      It does switch to using the generic le operations though, instead of
      any local varients.
      
      Build tested on ColdFire, 68328, 68360 (which is cpu32) and 68020+.
      Run tested on ColdFire and ARAnyM.
      Signed-off-by: default avatarGreg Ungerer <gerg@uclinux.org>
      Acked-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      171d809d
  5. 23 May, 2011 1 commit
  6. 30 Mar, 2011 1 commit
  7. 24 Mar, 2011 1 commit
    • Greg Ungerer's avatar
      m68k: merge m68k and m68knommu arch directories · 66d857b0
      Greg Ungerer authored
      There is a lot of common code that could be shared between the m68k
      and m68knommu arch branches. It makes sense to merge the two branches
      into a single directory structure so that we can more easily share
      that common code.
      
      This is a brute force merge, based on a script from Stephen King
      <sfking@fdwdc.com>, which was originally written by Arnd Bergmann
      <arnd@arndb.de>.
      
      > The script was inspired by the script Sam Ravnborg used to merge the
      > includes from m68knommu. For those files common to both arches but
      > differing in content, the m68k version of the file is renamed to
      > <file>_mm.<ext> and the m68knommu version of the file is moved into the
      > corresponding m68k directory and renamed <file>_no.<ext> and a small
      > wrapper file <file>.<ext> is used to select between the two version. Files
      > that are common to both but don't differ are removed from the m68knommu
      > tree and files and directories that are unique to the m68knommu tree are
      > moved to the m68k tree. Finally, the arch/m68knommu tree is removed.
      >
      > To select between the the versions of the files, the wrapper uses
      >
      > #ifdef CONFIG_MMU
      > #include <file>_mm.<ext>
      > #else
      > #include <file>_no.<ext>
      > #endif
      
      On top of this file merge I have done a simplistic merge of m68k and
      m68knommu Kconfig, which primarily attempts to keep existing options and
      menus in place. Other than a handful of options being moved it produces
      identical .config outputs on m68k and m68knommu targets I tested it on.
      
      With this in place there is now quite a bit of scope for merge cleanups
      in future patches.
      Signed-off-by: default avatarGreg Ungerer <gerg@uclinux.org>
      66d857b0
  8. 16 Mar, 2011 5 commits
  9. 22 Feb, 2011 1 commit
  10. 22 Oct, 2010 1 commit
  11. 19 Sep, 2010 1 commit
  12. 27 Jul, 2010 1 commit
  13. 26 May, 2010 1 commit
  14. 27 Feb, 2010 1 commit
  15. 30 Oct, 2009 1 commit
  16. 22 Sep, 2009 1 commit
  17. 06 Jan, 2009 1 commit
  18. 02 Jan, 2009 1 commit
  19. 20 Oct, 2008 1 commit
    • Matt Helsley's avatar
      container freezer: implement freezer cgroup subsystem · dc52ddc0
      Matt Helsley authored
      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: default avatarCedric Le Goater <clg@fr.ibm.com>
      Signed-off-by: default avatarMatt Helsley <matthltc@us.ibm.com>
      Acked-by: default avatarSerge E. Hallyn <serue@us.ibm.com>
      Tested-by: default avatarMatt Helsley <matthltc@us.ibm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      dc52ddc0
  20. 14 Oct, 2008 3 commits
  21. 06 Sep, 2008 2 commits
  22. 20 Jul, 2008 2 commits
  23. 18 May, 2008 2 commits
  24. 09 Feb, 2008 1 commit
  25. 08 Feb, 2008 2 commits
    • H. Peter Anvin's avatar
      avoid overflows in kernel/time.c · bdc80787
      H. Peter Anvin authored
      When the conversion factor between jiffies and milli- or microseconds is
      not a single multiply or divide, as for the case of HZ == 300, we currently
      do a multiply followed by a divide.  The intervening result, however, is
      subject to overflows, especially since the fraction is not simplified (for
      HZ == 300, we multiply by 300 and divide by 1000).
      
      This is exposed to the user when passing a large timeout to poll(), for
      example.
      
      This patch replaces the multiply-divide with a reciprocal multiplication on
      32-bit platforms.  When the input is an unsigned long, there is no portable
      way to do this on 64-bit platforms there is no portable way to do this
      since it requires a 128-bit intermediate result (which gcc does support on
      64-bit platforms but may generate libgcc calls, e.g.  on 64-bit s390), but
      since the output is a 32-bit integer in the cases affected, just simplify
      the multiply-divide (*3/10 instead of *300/1000).
      
      The reciprocal multiply used can have off-by-one errors in the upper half
      of the valid output range.  This could be avoided at the expense of having
      to deal with a potential 65-bit intermediate result.  Since the intent is
      to avoid overflow problems and most of the other time conversions are only
      semiexact, the off-by-one errors were considered an acceptable tradeoff.
      
      At Ralf Baechle's suggestion, this version uses a Perl script to compute
      the necessary constants.  We already have dependencies on Perl for kernel
      compiles.  This does, however, require the Perl module Math::BigInt, which
      is included in the standard Perl distribution starting with version 5.8.0.
      In order to support older versions of Perl, include a table of canned
      constants in the script itself, and structure the script so that
      Math::BigInt isn't required if pulling values from said table.
      
      Running the script requires that the HZ value is available from the
      Makefile.  Thus, this patch also adds the Kconfig variable CONFIG_HZ to the
      architectures which didn't already have it (alpha, cris, frv, h8300, m32r,
      m68k, m68knommu, sparc, v850, and xtensa.) It does *not* touch the sh or
      sh64 architectures, since Paul Mundt has dealt with those separately in the
      sh tree.
      Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>,
      Cc: Sam Ravnborg <sam@ravnborg.org>,
      Cc: Paul Mundt <lethal@linux-sh.org>,
      Cc: Richard Henderson <rth@twiddle.net>,
      Cc: Michael Starvik <starvik@axis.com>,
      Cc: David Howells <dhowells@redhat.com>,
      Cc: Yoshinori Sato <ysato@users.sourceforge.jp>,
      Cc: Hirokazu Takata <takata@linux-m32r.org>,
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
      Cc: Roman Zippel <zippel@linux-m68k.org>,
      Cc: William L. Irwin <sparclinux@vger.kernel.org>,
      Cc: Chris Zankel <chris@zankel.net>,
      Cc: H. Peter Anvin <hpa@zytor.com>,
      Cc: Jan Engelhardt <jengelh@computergmbh.de>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      bdc80787
    • David Howells's avatar
      aout: mark arches that support A.OUT format · b0b933c0
      David Howells authored
      Mark arches that support A.OUT format by including the following in their
      master Kconfig files:
      
      	config ARCH_SUPPORTS_AOUT
      		def_bool y
      
      This should also be set if the arch provides compatibility A.OUT support for
      an older arch, for instance x86_64 for i386 or sparc64 for sparc.
      
      I've guessed at which arches don't, based on comments in the code, however I'm
      sure that some of the ones I've marked as 'yes' actually should be 'no'.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Cc: <linux-arch@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      b0b933c0