You've already forked linux-apfs
mirror of
https://github.com/linux-apfs/linux-apfs.git
synced 2026-05-01 15:00:59 -07:00
Merge branch 'linux-2.6'
This commit is contained in:
Paul Mackerras
@@ -53,3 +53,5 @@ cscope.*
|
||||
|
||||
*.orig
|
||||
*.rej
|
||||
*~
|
||||
\#*#
|
||||
|
||||
@@ -183,8 +183,6 @@ i386/
|
||||
- directory with info about Linux on Intel 32 bit architecture.
|
||||
ia64/
|
||||
- directory with info about Linux on Intel 64 bit architecture.
|
||||
ide.txt
|
||||
- important info for users of ATA devices (IDE/EIDE disks and CD-ROMS).
|
||||
infiniband/
|
||||
- directory with documents concerning Linux InfiniBand support.
|
||||
initrd.txt
|
||||
|
||||
@@ -361,12 +361,14 @@ X!Edrivers/pnp/system.c
|
||||
<chapter id="blkdev">
|
||||
<title>Block Devices</title>
|
||||
!Eblock/blk-core.c
|
||||
!Iblock/blk-core.c
|
||||
!Eblock/blk-map.c
|
||||
!Iblock/blk-sysfs.c
|
||||
!Eblock/blk-settings.c
|
||||
!Eblock/blk-exec.c
|
||||
!Eblock/blk-barrier.c
|
||||
!Eblock/blk-tag.c
|
||||
!Iblock/blk-tag.c
|
||||
</chapter>
|
||||
|
||||
<chapter id="chrdev">
|
||||
|
||||
@@ -45,7 +45,7 @@ This driver provides the following features:
|
||||
---------------
|
||||
|
||||
0. The ide-cd relies on the ide disk driver. See
|
||||
Documentation/ide.txt for up-to-date information on the ide
|
||||
Documentation/ide/ide.txt for up-to-date information on the ide
|
||||
driver.
|
||||
|
||||
1. Make sure that the ide and ide-cd drivers are compiled into the
|
||||
@@ -64,7 +64,7 @@ This driver provides the following features:
|
||||
|
||||
Depending on what type of IDE interface you have, you may need to
|
||||
specify additional configuration options. See
|
||||
Documentation/ide.txt.
|
||||
Documentation/ide/ide.txt.
|
||||
|
||||
2. You should also ensure that the iso9660 filesystem is either
|
||||
compiled into the kernel or available as a loadable module. You
|
||||
@@ -84,7 +84,7 @@ This driver provides the following features:
|
||||
on the primary IDE interface are called `hda' and `hdb',
|
||||
respectively. The drives on the secondary interface are called
|
||||
`hdc' and `hdd'. (Interfaces at other locations get other letters
|
||||
in the third position; see Documentation/ide.txt.)
|
||||
in the third position; see Documentation/ide/ide.txt.)
|
||||
|
||||
If you want your CDROM drive to be found automatically by the
|
||||
driver, you should make sure your IDE interface uses either the
|
||||
@@ -93,7 +93,7 @@ This driver provides the following features:
|
||||
be jumpered as `master'. (If for some reason you cannot configure
|
||||
your system in this manner, you can probably still use the driver.
|
||||
You may have to pass extra configuration information to the kernel
|
||||
when you boot, however. See Documentation/ide.txt for more
|
||||
when you boot, however. See Documentation/ide/ide.txt for more
|
||||
information.)
|
||||
|
||||
4. Boot the system. If the drive is recognized, you should see a
|
||||
@@ -201,7 +201,7 @@ TEST
|
||||
This section discusses some common problems encountered when trying to
|
||||
use the driver, and some possible solutions. Note that if you are
|
||||
experiencing problems, you should probably also review
|
||||
Documentation/ide.txt for current information about the underlying
|
||||
Documentation/ide/ide.txt for current information about the underlying
|
||||
IDE support code. Some of these items apply only to earlier versions
|
||||
of the driver, but are mentioned here for completeness.
|
||||
|
||||
@@ -211,7 +211,7 @@ from the driver.
|
||||
a. Drive is not detected during booting.
|
||||
|
||||
- Review the configuration instructions above and in
|
||||
Documentation/ide.txt, and check how your hardware is
|
||||
Documentation/ide/ide.txt, and check how your hardware is
|
||||
configured.
|
||||
|
||||
- If your drive is the only device on an IDE interface, it should
|
||||
@@ -219,7 +219,7 @@ a. Drive is not detected during booting.
|
||||
|
||||
- If your IDE interface is not at the standard addresses of 0x170
|
||||
or 0x1f0, you'll need to explicitly inform the driver using a
|
||||
lilo option. See Documentation/ide.txt. (This feature was
|
||||
lilo option. See Documentation/ide/ide.txt. (This feature was
|
||||
added around kernel version 1.3.30.)
|
||||
|
||||
- If the autoprobing is not finding your drive, you can tell the
|
||||
@@ -245,7 +245,7 @@ a. Drive is not detected during booting.
|
||||
Support for some interfaces needing extra initialization is
|
||||
provided in later 1.3.x kernels. You may need to turn on
|
||||
additional kernel configuration options to get them to work;
|
||||
see Documentation/ide.txt.
|
||||
see Documentation/ide/ide.txt.
|
||||
|
||||
Even if support is not available for your interface, you may be
|
||||
able to get it to work with the following procedure. First boot
|
||||
@@ -299,7 +299,7 @@ c. System hangups.
|
||||
be worked around by specifying the `serialize' option when
|
||||
booting. Recent kernels should be able to detect the need for
|
||||
this automatically in most cases, but the detection is not
|
||||
foolproof. See Documentation/ide.txt for more information
|
||||
foolproof. See Documentation/ide/ide.txt for more information
|
||||
about the `serialize' option and the CMD640B.
|
||||
|
||||
- Note that many MS-DOS CDROM drivers will work with such buggy
|
||||
|
||||
@@ -1,4 +1,8 @@
|
||||
Memory Controller
|
||||
Memory Resource Controller
|
||||
|
||||
NOTE: The Memory Resource Controller has been generically been referred
|
||||
to as the memory controller in this document. Do not confuse memory controller
|
||||
used here with the memory controller that is used in hardware.
|
||||
|
||||
Salient features
|
||||
|
||||
@@ -152,7 +156,7 @@ The memory controller uses the following hierarchy
|
||||
|
||||
a. Enable CONFIG_CGROUPS
|
||||
b. Enable CONFIG_RESOURCE_COUNTERS
|
||||
c. Enable CONFIG_CGROUP_MEM_CONT
|
||||
c. Enable CONFIG_CGROUP_MEM_RES_CTLR
|
||||
|
||||
1. Prepare the cgroups
|
||||
# mkdir -p /cgroups
|
||||
@@ -164,7 +168,7 @@ c. Enable CONFIG_CGROUP_MEM_CONT
|
||||
|
||||
Since now we're in the 0 cgroup,
|
||||
We can alter the memory limit:
|
||||
# echo -n 4M > /cgroups/0/memory.limit_in_bytes
|
||||
# echo 4M > /cgroups/0/memory.limit_in_bytes
|
||||
|
||||
NOTE: We can use a suffix (k, K, m, M, g or G) to indicate values in kilo,
|
||||
mega or gigabytes.
|
||||
@@ -185,7 +189,7 @@ number of factors, such as rounding up to page boundaries or the total
|
||||
availability of memory on the system. The user is required to re-read
|
||||
this file after a write to guarantee the value committed by the kernel.
|
||||
|
||||
# echo -n 1 > memory.limit_in_bytes
|
||||
# echo 1 > memory.limit_in_bytes
|
||||
# cat memory.limit_in_bytes
|
||||
4096
|
||||
|
||||
@@ -197,7 +201,7 @@ caches, RSS and Active pages/Inactive pages are shown.
|
||||
|
||||
The memory.force_empty gives an interface to drop *all* charges by force.
|
||||
|
||||
# echo -n 1 > memory.force_empty
|
||||
# echo 1 > memory.force_empty
|
||||
|
||||
will drop all charges in cgroup. Currently, this is maintained for test.
|
||||
|
||||
|
||||
@@ -36,14 +36,15 @@ available (notebooks) or too slow for extensive debug information (like ACPI).
|
||||
Drivers
|
||||
-------
|
||||
|
||||
The OHCI-1394 drivers in drivers/firewire and drivers/ieee1394 initialize
|
||||
the OHCI-1394 controllers to a working state and can be used to enable
|
||||
physical DMA. By default you only have to load the driver, and physical
|
||||
DMA access will be granted to all remote nodes, but it can be turned off
|
||||
when using the ohci1394 driver.
|
||||
The ohci1394 driver in drivers/ieee1394 initializes the OHCI-1394 controllers
|
||||
to a working state and enables physical DMA by default for all remote nodes.
|
||||
This can be turned off by ohci1394's module parameter phys_dma=0.
|
||||
|
||||
Because these drivers depend on the PCI enumeration to be completed, an
|
||||
initialization routine which can runs pretty early (long before console_init(),
|
||||
The alternative firewire-ohci driver in drivers/firewire uses filtered physical
|
||||
DMA, hence is not yet suitable for remote debugging.
|
||||
|
||||
Because ohci1394 depends on the PCI enumeration to be completed, an
|
||||
initialization routine which runs pretty early (long before console_init()
|
||||
which makes the printk buffer appear on the console can be called) was written.
|
||||
|
||||
To activate it, enable CONFIG_PROVIDE_OHCI1394_DMA_INIT (Kernel hacking menu:
|
||||
|
||||
@@ -172,6 +172,16 @@ Who: Len Brown <len.brown@intel.com>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: ide-tape driver
|
||||
When: July 2008
|
||||
Files: drivers/ide/ide-tape.c
|
||||
Why: This driver might not have any users anymore and maintaining it for no
|
||||
reason is an effort no one wants to make.
|
||||
Who: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>, Borislav Petkov
|
||||
<petkovbb@googlemail.com>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: libata spindown skipping and warning
|
||||
When: Dec 2008
|
||||
Why: Some halt(8) implementations synchronize caches for and spin
|
||||
@@ -306,3 +316,15 @@ Why: Largely unmaintained and almost entirely unused. File system
|
||||
is largely pointless as without a lot of work only the most
|
||||
trivial of Solaris binaries can work with the emulation code.
|
||||
Who: David S. Miller <davem@davemloft.net>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: init_mm export
|
||||
When: 2.6.26
|
||||
Why: Not used in-tree. The current out-of-tree users used it to
|
||||
work around problems in the CPA code which should be resolved
|
||||
by now. One usecase was described to provide verification code
|
||||
of the CPA operation. That's a good idea in general, but such
|
||||
code / infrastructure should be in the kernel and not in some
|
||||
out-of-tree driver.
|
||||
Who: Thomas Gleixner <tglx@linutronix.de>
|
||||
|
||||
+12
-4
@@ -2,6 +2,9 @@ GPIO Interfaces
|
||||
|
||||
This provides an overview of GPIO access conventions on Linux.
|
||||
|
||||
These calls use the gpio_* naming prefix. No other calls should use that
|
||||
prefix, or the related __gpio_* prefix.
|
||||
|
||||
|
||||
What is a GPIO?
|
||||
===============
|
||||
@@ -69,11 +72,13 @@ in this document, but drivers acting as clients to the GPIO interface must
|
||||
not care how it's implemented.)
|
||||
|
||||
That said, if the convention is supported on their platform, drivers should
|
||||
use it when possible. Platforms should declare GENERIC_GPIO support in
|
||||
Kconfig (boolean true), which multi-platform drivers can depend on when
|
||||
using the include file:
|
||||
use it when possible. Platforms must declare GENERIC_GPIO support in their
|
||||
Kconfig (boolean true), and provide an <asm/gpio.h> file. Drivers that can't
|
||||
work without standard GPIO calls should have Kconfig entries which depend
|
||||
on GENERIC_GPIO. The GPIO calls are available, either as "real code" or as
|
||||
optimized-away stubs, when drivers use the include file:
|
||||
|
||||
#include <asm/gpio.h>
|
||||
#include <linux/gpio.h>
|
||||
|
||||
If you stick to this convention then it'll be easier for other developers to
|
||||
see what your code is doing, and help maintain it.
|
||||
@@ -316,6 +321,9 @@ pulldowns integrated on some platforms. Not all platforms support them,
|
||||
or support them in the same way; and any given board might use external
|
||||
pullups (or pulldowns) so that the on-chip ones should not be used.
|
||||
(When a circuit needs 5 kOhm, on-chip 100 kOhm resistors won't do.)
|
||||
Likewise drive strength (2 mA vs 20 mA) and voltage (1.8V vs 3.3V) is a
|
||||
platform-specific issue, as are models like (not) having a one-to-one
|
||||
correspondence between configurable pins and GPIOs.
|
||||
|
||||
There are other system-specific mechanisms that are not specified here,
|
||||
like the aforementioned options for input de-glitching and wire-OR output.
|
||||
|
||||
@@ -0,0 +1,12 @@
|
||||
00-INDEX
|
||||
- this file
|
||||
ChangeLog.ide-cd.1994-2004
|
||||
- ide-cd changelog
|
||||
ChangeLog.ide-floppy.1996-2002
|
||||
- ide-floppy changelog
|
||||
ChangeLog.ide-tape.1995-2002
|
||||
- ide-tape changelog
|
||||
ide-tape.txt
|
||||
- info on the IDE ATAPI streaming tape driver
|
||||
ide.txt
|
||||
- important info for users of ATA devices (IDE/EIDE disks and CD-ROMS).
|
||||
@@ -258,8 +258,6 @@ Summary of ide driver parameters for kernel command line
|
||||
As for VLB, it is safest to not specify it.
|
||||
Bigger values are safer than smaller ones.
|
||||
|
||||
"idex=noprobe" : do not attempt to access/use this interface
|
||||
|
||||
"idex=base" : probe for an interface at the addr specified,
|
||||
where "base" is usually 0x1f0 or 0x170
|
||||
and "ctl" is assumed to be "base"+0x206
|
||||
@@ -307,53 +305,6 @@ Also for legacy CMD640 host driver (cmd640) you need to use "probe_vlb"
|
||||
kernel paremeter to enable probing for VLB version of the chipset (PCI ones
|
||||
are detected automatically).
|
||||
|
||||
================================================================================
|
||||
|
||||
IDE ATAPI streaming tape driver
|
||||
-------------------------------
|
||||
|
||||
This driver is a part of the Linux ide driver and works in co-operation
|
||||
with linux/drivers/block/ide.c.
|
||||
|
||||
The driver, in co-operation with ide.c, basically traverses the
|
||||
request-list for the block device interface. The character device
|
||||
interface, on the other hand, creates new requests, adds them
|
||||
to the request-list of the block device, and waits for their completion.
|
||||
|
||||
Pipelined operation mode is now supported on both reads and writes.
|
||||
|
||||
The block device major and minor numbers are determined from the
|
||||
tape's relative position in the ide interfaces, as explained in ide.c.
|
||||
|
||||
The character device interface consists of the following devices:
|
||||
|
||||
ht0 major 37, minor 0 first IDE tape, rewind on close.
|
||||
ht1 major 37, minor 1 second IDE tape, rewind on close.
|
||||
...
|
||||
nht0 major 37, minor 128 first IDE tape, no rewind on close.
|
||||
nht1 major 37, minor 129 second IDE tape, no rewind on close.
|
||||
...
|
||||
|
||||
Run /dev/MAKEDEV to create the above entries.
|
||||
|
||||
The general magnetic tape commands compatible interface, as defined by
|
||||
include/linux/mtio.h, is accessible through the character device.
|
||||
|
||||
General ide driver configuration options, such as the interrupt-unmask
|
||||
flag, can be configured by issuing an ioctl to the block device interface,
|
||||
as any other ide device.
|
||||
|
||||
Our own ide-tape ioctl's can be issued to either the block device or
|
||||
the character device interface.
|
||||
|
||||
Maximal throughput with minimal bus load will usually be achieved in the
|
||||
following scenario:
|
||||
|
||||
1. ide-tape is operating in the pipelined operation mode.
|
||||
2. No buffering is performed by the user backup program.
|
||||
|
||||
|
||||
|
||||
================================================================================
|
||||
|
||||
Some Terminology
|
||||
@@ -712,7 +712,7 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||
Format: <cyl>,<head>,<sect>
|
||||
|
||||
hd?= [HW] (E)IDE subsystem
|
||||
hd?lun= See Documentation/ide.txt.
|
||||
hd?lun= See Documentation/ide/ide.txt.
|
||||
|
||||
highmem=nn[KMG] [KNL,BOOT] forces the highmem zone to have an exact
|
||||
size of <nn>. This works even on boxes that have no
|
||||
@@ -766,14 +766,14 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||
|
||||
ide= [HW] (E)IDE subsystem
|
||||
Format: ide=nodma or ide=doubler or ide=reverse
|
||||
See Documentation/ide.txt.
|
||||
See Documentation/ide/ide.txt.
|
||||
|
||||
ide?= [HW] (E)IDE subsystem
|
||||
Format: ide?=noprobe or chipset specific parameters.
|
||||
See Documentation/ide.txt.
|
||||
See Documentation/ide/ide.txt.
|
||||
|
||||
idebus= [HW] (E)IDE subsystem - VLB/PCI bus speed
|
||||
See Documentation/ide.txt.
|
||||
See Documentation/ide/ide.txt.
|
||||
|
||||
idle= [X86]
|
||||
Format: idle=poll or idle=mwait
|
||||
|
||||
+5
-238
@@ -192,7 +192,8 @@ code mapping.
|
||||
The Kprobes API includes a "register" function and an "unregister"
|
||||
function for each type of probe. Here are terse, mini-man-page
|
||||
specifications for these functions and the associated probe handlers
|
||||
that you'll write. See the latter half of this document for examples.
|
||||
that you'll write. See the files in the samples/kprobes/ sub-directory
|
||||
for examples.
|
||||
|
||||
4.1 register_kprobe
|
||||
|
||||
@@ -420,249 +421,15 @@ e. Watchpoint probes (which fire on data references).
|
||||
|
||||
8. Kprobes Example
|
||||
|
||||
Here's a sample kernel module showing the use of kprobes to dump a
|
||||
stack trace and selected i386 registers when do_fork() is called.
|
||||
----- cut here -----
|
||||
/*kprobe_example.c*/
|
||||
#include <linux/kernel.h>
|
||||
#include <linux/module.h>
|
||||
#include <linux/kprobes.h>
|
||||
#include <linux/sched.h>
|
||||
|
||||
/*For each probe you need to allocate a kprobe structure*/
|
||||
static struct kprobe kp;
|
||||
|
||||
/*kprobe pre_handler: called just before the probed instruction is executed*/
|
||||
int handler_pre(struct kprobe *p, struct pt_regs *regs)
|
||||
{
|
||||
printk("pre_handler: p->addr=0x%p, eip=%lx, eflags=0x%lx\n",
|
||||
p->addr, regs->eip, regs->eflags);
|
||||
dump_stack();
|
||||
return 0;
|
||||
}
|
||||
|
||||
/*kprobe post_handler: called after the probed instruction is executed*/
|
||||
void handler_post(struct kprobe *p, struct pt_regs *regs, unsigned long flags)
|
||||
{
|
||||
printk("post_handler: p->addr=0x%p, eflags=0x%lx\n",
|
||||
p->addr, regs->eflags);
|
||||
}
|
||||
|
||||
/* fault_handler: this is called if an exception is generated for any
|
||||
* instruction within the pre- or post-handler, or when Kprobes
|
||||
* single-steps the probed instruction.
|
||||
*/
|
||||
int handler_fault(struct kprobe *p, struct pt_regs *regs, int trapnr)
|
||||
{
|
||||
printk("fault_handler: p->addr=0x%p, trap #%dn",
|
||||
p->addr, trapnr);
|
||||
/* Return 0 because we don't handle the fault. */
|
||||
return 0;
|
||||
}
|
||||
|
||||
static int __init kprobe_init(void)
|
||||
{
|
||||
int ret;
|
||||
kp.pre_handler = handler_pre;
|
||||
kp.post_handler = handler_post;
|
||||
kp.fault_handler = handler_fault;
|
||||
kp.symbol_name = "do_fork";
|
||||
|
||||
ret = register_kprobe(&kp);
|
||||
if (ret < 0) {
|
||||
printk("register_kprobe failed, returned %d\n", ret);
|
||||
return ret;
|
||||
}
|
||||
printk("kprobe registered\n");
|
||||
return 0;
|
||||
}
|
||||
|
||||
static void __exit kprobe_exit(void)
|
||||
{
|
||||
unregister_kprobe(&kp);
|
||||
printk("kprobe unregistered\n");
|
||||
}
|
||||
|
||||
module_init(kprobe_init)
|
||||
module_exit(kprobe_exit)
|
||||
MODULE_LICENSE("GPL");
|
||||
----- cut here -----
|
||||
|
||||
You can build the kernel module, kprobe-example.ko, using the following
|
||||
Makefile:
|
||||
----- cut here -----
|
||||
obj-m := kprobe-example.o
|
||||
KDIR := /lib/modules/$(shell uname -r)/build
|
||||
PWD := $(shell pwd)
|
||||
default:
|
||||
$(MAKE) -C $(KDIR) SUBDIRS=$(PWD) modules
|
||||
clean:
|
||||
rm -f *.mod.c *.ko *.o
|
||||
----- cut here -----
|
||||
|
||||
$ make
|
||||
$ su -
|
||||
...
|
||||
# insmod kprobe-example.ko
|
||||
|
||||
You will see the trace data in /var/log/messages and on the console
|
||||
whenever do_fork() is invoked to create a new process.
|
||||
See samples/kprobes/kprobe_example.c
|
||||
|
||||
9. Jprobes Example
|
||||
|
||||
Here's a sample kernel module showing the use of jprobes to dump
|
||||
the arguments of do_fork().
|
||||
----- cut here -----
|
||||
/*jprobe-example.c */
|
||||
#include <linux/kernel.h>
|
||||
#include <linux/module.h>
|
||||
#include <linux/fs.h>
|
||||
#include <linux/uio.h>
|
||||
#include <linux/kprobes.h>
|
||||
|
||||
/*
|
||||
* Jumper probe for do_fork.
|
||||
* Mirror principle enables access to arguments of the probed routine
|
||||
* from the probe handler.
|
||||
*/
|
||||
|
||||
/* Proxy routine having the same arguments as actual do_fork() routine */
|
||||
long jdo_fork(unsigned long clone_flags, unsigned long stack_start,
|
||||
struct pt_regs *regs, unsigned long stack_size,
|
||||
int __user * parent_tidptr, int __user * child_tidptr)
|
||||
{
|
||||
printk("jprobe: clone_flags=0x%lx, stack_size=0x%lx, regs=0x%p\n",
|
||||
clone_flags, stack_size, regs);
|
||||
/* Always end with a call to jprobe_return(). */
|
||||
jprobe_return();
|
||||
/*NOTREACHED*/
|
||||
return 0;
|
||||
}
|
||||
|
||||
static struct jprobe my_jprobe = {
|
||||
.entry = jdo_fork
|
||||
};
|
||||
|
||||
static int __init jprobe_init(void)
|
||||
{
|
||||
int ret;
|
||||
my_jprobe.kp.symbol_name = "do_fork";
|
||||
|
||||
if ((ret = register_jprobe(&my_jprobe)) <0) {
|
||||
printk("register_jprobe failed, returned %d\n", ret);
|
||||
return -1;
|
||||
}
|
||||
printk("Planted jprobe at %p, handler addr %p\n",
|
||||
my_jprobe.kp.addr, my_jprobe.entry);
|
||||
return 0;
|
||||
}
|
||||
|
||||
static void __exit jprobe_exit(void)
|
||||
{
|
||||
unregister_jprobe(&my_jprobe);
|
||||
printk("jprobe unregistered\n");
|
||||
}
|
||||
|
||||
module_init(jprobe_init)
|
||||
module_exit(jprobe_exit)
|
||||
MODULE_LICENSE("GPL");
|
||||
----- cut here -----
|
||||
|
||||
Build and insert the kernel module as shown in the above kprobe
|
||||
example. You will see the trace data in /var/log/messages and on
|
||||
the console whenever do_fork() is invoked to create a new process.
|
||||
(Some messages may be suppressed if syslogd is configured to
|
||||
eliminate duplicate messages.)
|
||||
See samples/kprobes/jprobe_example.c
|
||||
|
||||
10. Kretprobes Example
|
||||
|
||||
Here's a sample kernel module showing the use of return probes to
|
||||
report failed calls to sys_open().
|
||||
----- cut here -----
|
||||
/*kretprobe-example.c*/
|
||||
#include <linux/kernel.h>
|
||||
#include <linux/module.h>
|
||||
#include <linux/kprobes.h>
|
||||
#include <linux/ktime.h>
|
||||
|
||||
/* per-instance private data */
|
||||
struct my_data {
|
||||
ktime_t entry_stamp;
|
||||
};
|
||||
|
||||
static const char *probed_func = "sys_open";
|
||||
|
||||
/* Timestamp function entry. */
|
||||
static int entry_handler(struct kretprobe_instance *ri, struct pt_regs *regs)
|
||||
{
|
||||
struct my_data *data;
|
||||
|
||||
if(!current->mm)
|
||||
return 1; /* skip kernel threads */
|
||||
|
||||
data = (struct my_data *)ri->data;
|
||||
data->entry_stamp = ktime_get();
|
||||
return 0;
|
||||
}
|
||||
|
||||
/* If the probed function failed, log the return value and duration.
|
||||
* Duration may turn out to be zero consistently, depending upon the
|
||||
* granularity of time accounting on the platform. */
|
||||
static int return_handler(struct kretprobe_instance *ri, struct pt_regs *regs)
|
||||
{
|
||||
int retval = regs_return_value(regs);
|
||||
struct my_data *data = (struct my_data *)ri->data;
|
||||
s64 delta;
|
||||
ktime_t now;
|
||||
|
||||
if (retval < 0) {
|
||||
now = ktime_get();
|
||||
delta = ktime_to_ns(ktime_sub(now, data->entry_stamp));
|
||||
printk("%s: return val = %d (duration = %lld ns)\n",
|
||||
probed_func, retval, delta);
|
||||
}
|
||||
return 0;
|
||||
}
|
||||
|
||||
static struct kretprobe my_kretprobe = {
|
||||
.handler = return_handler,
|
||||
.entry_handler = entry_handler,
|
||||
.data_size = sizeof(struct my_data),
|
||||
.maxactive = 20, /* probe up to 20 instances concurrently */
|
||||
};
|
||||
|
||||
static int __init kretprobe_init(void)
|
||||
{
|
||||
int ret;
|
||||
my_kretprobe.kp.symbol_name = (char *)probed_func;
|
||||
|
||||
if ((ret = register_kretprobe(&my_kretprobe)) < 0) {
|
||||
printk("register_kretprobe failed, returned %d\n", ret);
|
||||
return -1;
|
||||
}
|
||||
printk("Kretprobe active on %s\n", my_kretprobe.kp.symbol_name);
|
||||
return 0;
|
||||
}
|
||||
|
||||
static void __exit kretprobe_exit(void)
|
||||
{
|
||||
unregister_kretprobe(&my_kretprobe);
|
||||
printk("kretprobe unregistered\n");
|
||||
/* nmissed > 0 suggests that maxactive was set too low. */
|
||||
printk("Missed probing %d instances of %s\n",
|
||||
my_kretprobe.nmissed, probed_func);
|
||||
}
|
||||
|
||||
module_init(kretprobe_init)
|
||||
module_exit(kretprobe_exit)
|
||||
MODULE_LICENSE("GPL");
|
||||
----- cut here -----
|
||||
|
||||
Build and insert the kernel module as shown in the above kprobe
|
||||
example. You will see the trace data in /var/log/messages and on the
|
||||
console whenever sys_open() returns a negative value. (Some messages
|
||||
may be suppressed if syslogd is configured to eliminate duplicate
|
||||
messages.)
|
||||
See samples/kprobes/kretprobe_example.c
|
||||
|
||||
For additional information on Kprobes, refer to the following URLs:
|
||||
http://www-106.ibm.com/developerworks/library/l-kprobes.html?ca=dgr-lnxw42Kprobe
|
||||
|
||||
@@ -486,9 +486,12 @@ static void concat(char *dst, char *args[])
|
||||
unsigned int i, len = 0;
|
||||
|
||||
for (i = 0; args[i]; i++) {
|
||||
strcpy(dst+len, args[i]);
|
||||
if (i) {
|
||||
strcat(dst+len, " ");
|
||||
len += strlen(args[i]) + 1;
|
||||
len++;
|
||||
}
|
||||
strcpy(dst+len, args[i]);
|
||||
len += strlen(args[i]);
|
||||
}
|
||||
/* In case it's empty. */
|
||||
dst[len] = '\0';
|
||||
|
||||
@@ -123,7 +123,8 @@ initialization with a pointer to a structure describing the driver
|
||||
|
||||
|
||||
The ID table is an array of struct pci_device_id entries ending with an
|
||||
all-zero entry. Each entry consists of:
|
||||
all-zero entry; use of the macro DEFINE_PCI_DEVICE_TABLE is the preferred
|
||||
method of declaring the table. Each entry consists of:
|
||||
|
||||
vendor,device Vendor and device ID to match (or PCI_ANY_ID)
|
||||
|
||||
@@ -191,7 +192,8 @@ Tips on when/where to use the above attributes:
|
||||
|
||||
o Do not mark the struct pci_driver.
|
||||
|
||||
o The ID table array should be marked __devinitdata.
|
||||
o The ID table array should be marked __devinitconst; this is done
|
||||
automatically if the table is declared with DEFINE_PCI_DEVICE_TABLE().
|
||||
|
||||
o The probe() and remove() functions should be marked __devinit
|
||||
and __devexit respectively. All initialization functions
|
||||
|
||||
@@ -142,7 +142,7 @@ of idleness (idle, busy, and newly idle):
|
||||
|
||||
/proc/<pid>/schedstat
|
||||
----------------
|
||||
schedstats also adds a new /proc/<pid/schedstat file to include some of
|
||||
schedstats also adds a new /proc/<pid>/schedstat file to include some of
|
||||
the same information on a per-process level. There are three fields in
|
||||
this file correlating for that process to:
|
||||
1) time spent on the cpu
|
||||
|
||||
@@ -109,4 +109,10 @@
|
||||
** 8.replace pci_alloc_consistent()/pci_free_consistent() with kmalloc()/kfree() in arcmsr_iop_message_xfer()
|
||||
** 9. fix the release of dma memory for type B in arcmsr_free_ccb_pool()
|
||||
** 10.fix the arcmsr_polling_hbb_ccbdone()
|
||||
** 1.20.00.15 02/27/2008 Erich Chen & Nick Cheng
|
||||
** 1.arcmsr_iop_message_xfer() is called from atomic context under the
|
||||
** queuecommand scsi_host_template handler. James Bottomley pointed out
|
||||
** that the current GFP_KERNEL|GFP_DMA flags are wrong: firstly we are in
|
||||
** atomic context, secondly this memory is not used for DMA.
|
||||
** Also removed some unneeded casts. Thanks to Daniel Drake <dsd@gentoo.org>
|
||||
**************************************************************************
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
usb-help.txt
|
||||
2000-July-12
|
||||
2008-Mar-7
|
||||
|
||||
For USB help other than the readme files that are located in
|
||||
Documentation/usb/*, see the following:
|
||||
@@ -11,8 +11,6 @@ Linux USB Guide: http://linux-usb.sourceforge.net
|
||||
Linux-USB device overview (working devices and drivers):
|
||||
http://www.qbik.ch/usb/devices/
|
||||
|
||||
The Linux-USB mailing lists are:
|
||||
linux-usb-users@lists.sourceforge.net for general user help
|
||||
linux-usb-devel@lists.sourceforge.net for developer discussions
|
||||
The Linux-USB mailing list is at linux-usb@vger.kernel.org
|
||||
|
||||
###
|
||||
|
||||
@@ -50,14 +50,14 @@ F.e. in order to boot just with sanity checks and red zoning one would specify:
|
||||
|
||||
Trying to find an issue in the dentry cache? Try
|
||||
|
||||
slub_debug=,dentry_cache
|
||||
slub_debug=,dentry
|
||||
|
||||
to only enable debugging on the dentry cache.
|
||||
|
||||
Red zoning and tracking may realign the slab. We can just apply sanity checks
|
||||
to the dentry cache with
|
||||
|
||||
slub_debug=F,dentry_cache
|
||||
slub_debug=F,dentry
|
||||
|
||||
In case you forgot to enable debugging on the kernel command line: It is
|
||||
possible to enable debugging manually when the kernel is up. Look at the
|
||||
|
||||
+46
-35
@@ -767,14 +767,14 @@ S: Maintained
|
||||
|
||||
BLACKFIN ARCHITECTURE
|
||||
P: Bryan Wu
|
||||
M: bryan.wu@analog.com
|
||||
M: cooloney@kernel.org
|
||||
L: uclinux-dist-devel@blackfin.uclinux.org (subscribers-only)
|
||||
W: http://blackfin.uclinux.org
|
||||
S: Supported
|
||||
|
||||
BLACKFIN EMAC DRIVER
|
||||
P: Bryan Wu
|
||||
M: bryan.wu@analog.com
|
||||
M: cooloney@kernel.org
|
||||
L: uclinux-dist-devel@blackfin.uclinux.org (subscribers-only)
|
||||
W: http://blackfin.uclinux.org
|
||||
S: Supported
|
||||
@@ -982,6 +982,12 @@ M: mchan@broadcom.com
|
||||
L: netdev@vger.kernel.org
|
||||
S: Supported
|
||||
|
||||
BROADCOM BNX2X 10 GIGABIT ETHERNET DRIVER
|
||||
P: Eliezer Tamir
|
||||
M: eliezert@broadcom.com
|
||||
L: netdev@vger.kernel.org
|
||||
S: Supported
|
||||
|
||||
BROADCOM TG3 GIGABIT ETHERNET DRIVER
|
||||
P: Michael Chan
|
||||
M: mchan@broadcom.com
|
||||
@@ -1132,6 +1138,12 @@ L: accessrunner-general@lists.sourceforge.net
|
||||
W: http://accessrunner.sourceforge.net/
|
||||
S: Maintained
|
||||
|
||||
CONTROL GROUPS (CGROUPS)
|
||||
P: Paul Menage
|
||||
M: menage@google.com
|
||||
L: containers@lists.linux-foundation.org
|
||||
S: Maintained
|
||||
|
||||
CORETEMP HARDWARE MONITORING DRIVER
|
||||
P: Rudolf Marek
|
||||
M: r.marek@assembler.cz
|
||||
@@ -1583,6 +1595,13 @@ L: linux-fbdev-devel@lists.sourceforge.net (moderated for non-subscribers)
|
||||
W: http://linux-fbdev.sourceforge.net/
|
||||
S: Maintained
|
||||
|
||||
FREESCALE DMA DRIVER
|
||||
P; Zhang Wei
|
||||
M: wei.zhang@freescale.com
|
||||
L: linuxppc-embedded@ozlabs.org
|
||||
L: linux-kernel@vger.kernel.org
|
||||
S: Maintained
|
||||
|
||||
FREESCALE SOC FS_ENET DRIVER
|
||||
P: Pantelis Antoniou
|
||||
M: pantelis.antoniou@gmail.com
|
||||
@@ -2033,43 +2052,19 @@ M: kernel@wantstofly.org
|
||||
L: netdev@vger.kernel.org
|
||||
S: Maintained
|
||||
|
||||
INTEL PRO/100 ETHERNET SUPPORT
|
||||
INTEL ETHERNET DRIVERS (e100/e1000/e1000e/igb/ixgb/ixgbe)
|
||||
P: Auke Kok
|
||||
M: auke-jan.h.kok@intel.com
|
||||
P: Jesse Brandeburg
|
||||
M: jesse.brandeburg@intel.com
|
||||
P: Jeff Kirsher
|
||||
M: jeffrey.t.kirsher@intel.com
|
||||
P: Bruce Allan
|
||||
M: bruce.w.allan@intel.com
|
||||
P: John Ronciak
|
||||
M: john.ronciak@intel.com
|
||||
L: e1000-devel@lists.sourceforge.net
|
||||
W: http://sourceforge.net/projects/e1000/
|
||||
S: Supported
|
||||
|
||||
INTEL PRO/1000 GIGABIT ETHERNET SUPPORT
|
||||
P: Auke Kok
|
||||
M: auke-jan.h.kok@intel.com
|
||||
P: Jesse Brandeburg
|
||||
M: jesse.brandeburg@intel.com
|
||||
P: Jeff Kirsher
|
||||
M: jeffrey.t.kirsher@intel.com
|
||||
P: John Ronciak
|
||||
M: john.ronciak@intel.com
|
||||
L: e1000-devel@lists.sourceforge.net
|
||||
W: http://sourceforge.net/projects/e1000/
|
||||
S: Supported
|
||||
|
||||
INTEL PRO/10GbE SUPPORT
|
||||
P: Ayyappan Veeraiyan
|
||||
M: ayyappan.veeraiyan@intel.com
|
||||
P: Auke Kok
|
||||
M: auke-jan.h.kok@intel.com
|
||||
P: Jesse Brandeburg
|
||||
M: jesse.brandeburg@intel.com
|
||||
P: John Ronciak
|
||||
M: john.ronciak@intel.com
|
||||
L: e1000-devel@lists.sourceforge.net
|
||||
W: http://sourceforge.net/projects/e1000/
|
||||
W: http://e1000.sourceforge.net/
|
||||
S: Supported
|
||||
|
||||
INTEL PRO/WIRELESS 2100 NETWORK CONNECTION SUPPORT
|
||||
@@ -2137,7 +2132,7 @@ L: netdev@vger.kernel.org
|
||||
S: Maintained
|
||||
|
||||
IPATH DRIVER:
|
||||
P: Arthur Jones
|
||||
P: Ralph Campbell
|
||||
M: infinipath@qlogic.com
|
||||
L: general@lists.openfabrics.org
|
||||
T: git git://git.qlogic.com/ipath-linux-2.6
|
||||
@@ -2620,6 +2615,17 @@ L: linux-kernel@vger.kernel.org
|
||||
W: http://www.linux-mm.org
|
||||
S: Maintained
|
||||
|
||||
MEMORY RESOURCE CONTROLLER
|
||||
P: Balbir Singh
|
||||
M: balbir@linux.vnet.ibm.com
|
||||
P: Pavel Emelyanov
|
||||
M: xemul@openvz.org
|
||||
P: KAMEZAWA Hiroyuki
|
||||
M: kamezawa.hiroyu@jp.fujitsu.com
|
||||
L: linux-mm@kvack.org
|
||||
L: linux-kernel@vger.kernel.org
|
||||
S: Maintained
|
||||
|
||||
MEI MN10300/AM33 PORT
|
||||
P: David Howells
|
||||
M: dhowells@redhat.com
|
||||
@@ -2744,6 +2750,8 @@ S: Maintained
|
||||
NETEFFECT IWARP RNIC DRIVER (IW_NES)
|
||||
P: Faisal Latif
|
||||
M: flatif@neteffect.com
|
||||
P: Nishi Gupta
|
||||
M: ngupta@neteffect.com
|
||||
P: Glenn Streiff
|
||||
M: gstreiff@neteffect.com
|
||||
L: general@lists.openfabrics.org
|
||||
@@ -3884,10 +3892,13 @@ M: trivial@kernel.org
|
||||
L: linux-kernel@vger.kernel.org
|
||||
S: Maintained
|
||||
|
||||
TULIP NETWORK DRIVER
|
||||
L: tulip-users@lists.sourceforge.net
|
||||
W: http://sourceforge.net/projects/tulip/
|
||||
S: Orphan
|
||||
TULIP NETWORK DRIVERS
|
||||
P: Grant Grundler
|
||||
M: grundler@parisc-linux.org
|
||||
P: Kyle McMartin
|
||||
M: kyle@parisc-linux.org
|
||||
L: netdev@vger.kernel.org
|
||||
S: Maintained
|
||||
|
||||
TUN/TAP driver
|
||||
P: Maxim Krasnyansky
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
VERSION = 2
|
||||
PATCHLEVEL = 6
|
||||
SUBLEVEL = 25
|
||||
EXTRAVERSION = -rc3
|
||||
EXTRAVERSION = -rc5
|
||||
NAME = Funky Weasel is Jiggy wit it
|
||||
|
||||
# *DOCUMENTATION*
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user