Skip to content

K
kernel_linux

OpenHarmony / kernel_linux
上一次同步 3 年多

通知 13
Star 8
Fork 2
K
kernel_linux
切换分支/标签
  1. 03 12月, 2008 1 次提交
  3. 01 12月, 2008 1 次提交
  5. 13 11月, 2008 12 次提交
  7. 20 10月, 2008 2 次提交
    • A
      mn10300: use bcd2bin/bin2bcd · f6a2298c
      由 Adrian Bunk 提交于 
      Change mn10300 to use the new bcd2bin/bin2bcd functions instead of the
obsolete BCD_TO_BIN/BIN_TO_BCD macros.
Signed-off-by: NAdrian Bunk <bunk@kernel.org>
Acked-by: NDavid Howells <dhowells@redhat.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      f6a2298c
    • 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
  9. 02 10月, 2008 1 次提交
    • D
      MN10300: Fix IRQ handling · d6478fad
      由 David Howells 提交于 
      Fix the IRQ handling on the MN10300 arch.

This patch makes a number of significant changes:

 (1) It separates the irq_chip definition for edge-triggered interrupts from
     the one for level-triggered interrupts.

     This is necessary because the MN10300 PIC latches the IRQ channel's
     interrupt request bit (GxICR_REQUEST), even after the device has ceased to
     assert its interrupt line and the interrupt channel has been disabled in
     the PIC.  So for level-triggered interrupts we need to clear this bit when
     we re-enable - which is achieved by setting GxICR_DETECT but not
     GxICR_REQUEST when writing to the register.

     Not doing this results in spurious interrupts occurring because calling
     mask_ack() at the start of handle_level_irq() is insufficient - it fails
     to clear the REQUEST latch because the device that caused the interrupt is
     still asserting its interrupt line at this point.

 (2) IRQ disablement [irq_chip::disable_irq()] shouldn't clear the interrupt
     request flag for edge-triggered interrupts lest it lose an interrupt.

 (3) IRQ unmasking [irq_chip::unmask_irq()] also shouldn't clear the interrupt
     request flag for edge-triggered interrupts lest it lose an interrupt.

 (4) The end() operation is now left to the default (no-operation) as
     __do_IRQ() is compiled out.  This may affect misrouted_irq(), but
     according to Thomas Gleixner it's the correct thing to do.

 (5) handle_level_irq() is used for edge-triggered interrupts rather than
     handle_edge_irq() as the MN10300 PIC latches interrupt events even on
     masked IRQ channels, thus rendering IRQ_PENDING unnecessary.  It is
     sufficient to call mask_ack() at the start and unmask() at the end.

 (6) For level-triggered interrupts, ack() is now NULL as it's not used, and
     there is no effective ACK function on the PIC.  mask_ack() is now the
     same as mask() as the latch continues to latch, even when the channel is
     masked.

Further, the patch discards the disable() op implementation as its now the same
as the mask() op implementation, which is used instead.

It also discards the enable() op implementations as they're now the same as
the unmask() op implementations, which are used instead.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      d6478fad
  11. 25 9月, 2008 1 次提交
  13. 12 9月, 2008 1 次提交
  15. 07 9月, 2008 1 次提交
  17. 24 8月, 2008 1 次提交
  19. 05 8月, 2008 1 次提交
  21. 02 8月, 2008 1 次提交
  23. 27 7月, 2008 2 次提交
  25. 26 7月, 2008 1 次提交
    • T
      inflate: refactor inflate malloc code · 2d6ffcca
      由 Thomas Petazzoni 提交于 
      Inflate requires some dynamic memory allocation very early in the boot
process and this is provided with a set of four functions:
malloc/free/gzip_mark/gzip_release.

The old inflate code used a mark/release strategy rather than implement
free.  This new version instead keeps a count on the number of outstanding
allocations and when it hits zero, it resets the malloc arena.

This allows removing all the mark and release implementations and unifying
all the malloc/free implementations.

The architecture-dependent code must define two addresses:
 - free_mem_ptr, the address of the beginning of the area in which
   allocations should be made
 - free_mem_end_ptr, the address of the end of the area in which
   allocations should be made. If set to 0, then no check is made on
   the number of allocations, it just grows as much as needed

The architecture-dependent code can also provide an arch_decomp_wdog()
function call.  This function will be called several times during the
decompression process, and allow to notify the watchdog that the system is
still running.  If an architecture provides such a call, then it must
define ARCH_HAS_DECOMP_WDOG so that the generic inflate code calls
arch_decomp_wdog().

Work initially done by Matt Mackall, updated to a recent version of the
kernel and improved by me.

[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Matt Mackall <mpm@selenic.com>
Cc: Richard Henderson <rth@twiddle.net>
Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Cc: Mikael Starvik <mikael.starvik@axis.com>
Cc: Jesper Nilsson <jesper.nilsson@axis.com>
Cc: Haavard Skinnemoen <hskinnemoen@atmel.com>
Cc: David Howells <dhowells@redhat.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Acked-by: NPaul Mundt <lethal@linux-sh.org>
Acked-by: NYoshinori Sato <ysato@users.sourceforge.jp>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      2d6ffcca
  27. 25 7月, 2008 1 次提交
  29. 21 7月, 2008 1 次提交
  31. 05 7月, 2008 2 次提交
  33. 17 6月, 2008 1 次提交
  35. 17 5月, 2008 1 次提交
  37. 13 5月, 2008 1 次提交
  39. 11 5月, 2008 1 次提交
    • L
      BKL: revert back to the old spinlock implementation · 8e3e076c
      由 Linus Torvalds 提交于 
      The generic semaphore rewrite had a huge performance regression on AIM7
(and potentially other BKL-heavy benchmarks) because the generic
semaphores had been rewritten to be simple to understand and fair.  The
latter, in particular, turns a semaphore-based BKL implementation into a
mess of scheduling.

The attempt to fix the performance regression failed miserably (see the
previous commit 00b41ec2 'Revert
"semaphore: fix"'), and so for now the simple and sane approach is to
instead just go back to the old spinlock-based BKL implementation that
never had any issues like this.

This patch also has the advantage of being reported to fix the
regression completely according to Yanmin Zhang, unlike the semaphore
hack which still left a couple percentage point regression.

As a spinlock, the BKL obviously has the potential to be a latency
issue, but it's not really any different from any other spinlock in that
respect.  We do want to get rid of the BKL asap, but that has been the
plan for several years.

These days, the biggest users are in the tty layer (open/release in
particular) and Alan holds out some hope:

  "tty release is probably a few months away from getting cured - I'm
   afraid it will almost certainly be the very last user of the BKL in
   tty to get fixed as it depends on everything else being sanely locked."

so while we're not there yet, we do have a plan of action.
Tested-by: NYanmin Zhang <yanmin_zhang@linux.intel.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: Matthew Wilcox <matthew@wil.cx>
Cc: Alexander Viro <viro@ftp.linux.org.uk>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      8e3e076c
  41. 04 5月, 2008 1 次提交
    • U
      unified (weak) sys_pipe implementation · d35c7b0e
      由 Ulrich Drepper 提交于 
      This replaces the duplicated arch-specific versions of "sys_pipe()" with
one unified implementation.  This removes almost 250 lines of duplicated
code.

It's marked __weak, so that *if* an architecture wants to override the
default implementation it can do so by simply having its own replacement
version, since many architectures use alternate calling conventions for
the 'pipe()' system call for legacy reasons (ie traditional UNIX
implementations often return the two file descriptors in registers)

I still haven't changed the cris version even though Linus says the BKL
isn't needed.  The arch maintainer can easily do it if there are really
no obstacles.
Signed-off-by: NUlrich Drepper <drepper@redhat.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      d35c7b0e
  43. 29 4月, 2008 2 次提交
  45. 21 4月, 2008 1 次提交
    • G
      PCI: remove initial bios sort of PCI devices on x86 · 1ba6ab11
      由 Greg Kroah-Hartman 提交于 
      We currently keep 2 lists of PCI devices in the system, one in the
driver core, and one all on its own.  This second list is sorted at boot
time, in "BIOS" order, to try to remain compatible with older kernels
(2.2 and earlier days).  There was also a "nosort" option to turn this
sorting off, to remain compatible with even older kernel versions, but
that just ends up being what we have been doing from 2.5 days...

Unfortunately, the second list of devices is not really ever used to 
determine the probing order of PCI devices or drivers[1].  That is done
using the driver core list instead.  This change happened back in the
early 2.5 days.

Relying on BIOS ording for the binding of drivers to specific device
names is problematic for many reasons, and userspace tools like udev
exist to properly name devices in a persistant manner if that is needed,
no reliance on the BIOS is needed.

Matt Domsch and others at Dell noticed this back in 2006, and added a
boot option to sort the PCI device lists (both of them) in a
breadth-first manner to help remain compatible with the 2.4 order, if
needed for any reason.  This option is not going away, as some systems
rely on them.

This patch removes the sorting of the internal PCI device list in "BIOS"
mode, as it's not needed at all anymore, and hasn't for many years.
I've also removed the PCI flags for this from some other arches that for
some reason defined them, but never used them.

This should not change the ordering of any drivers or device probing.

[1] The old-style pci_get_device and pci_find_device() still used this
sorting order, but there are very few drivers that use these functions,
as they are deprecated for use in this manner.  If for some reason, a
driver rely on the order and uses these functions, the breadth-first
boot option will resolve any problem.

Cc: Matt Domsch <Matt_Domsch@dell.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      1ba6ab11
  47. 17 4月, 2008 1 次提交
  49. 24 2月, 2008 1 次提交