Merge branch 'master' of /home/src/linux-2.6/

Device-mapper snapshot support

==============================

Device-mapper allows you, without massive data copying:

*) To create snapshots of any block device i.e. mountable, saved states of

the block device which are also writable without interfering with the

original content;

*) To create device "forks", i.e. multiple different versions of the

same data stream.

In both cases, dm copies only the chunks of data that get changed and

uses a separate copy-on-write (COW) block device for storage.

There are two dm targets available: snapshot and snapshot-origin.

*) snapshot-origin <origin>

which will normally have one or more snapshots based on it.

You must create the snapshot-origin device before you can create snapshots.

Reads will be mapped directly to the backing device. For each write, the

original data will be saved in the <COW device> of each snapshot to keep

its visible content unchanged, at least until the <COW device> fills up.

*) snapshot <origin> <COW device> <persistent?> <chunksize>

A snapshot is created of the <origin> block device. Changed chunks of

<chunksize> sectors will be stored on the <COW device>.  Writes will

only go to the <COW device>.  Reads will come from the <COW device> or

from <origin> for unchanged data.  <COW device> will often be

smaller than the origin and if it fills up the snapshot will become

useless and be disabled, returning errors.  So it is important to monitor

the amount of free space and expand the <COW device> before it fills up.

<persistent?> is P (Persistent) or N (Not persistent - will not survive

after reboot).

How this is used by LVM2

========================

When you create the first LVM2 snapshot of a volume, four dm devices are used:

1) a device containing the original mapping table of the source volume;

2) a device used as the <COW device>;

3) a "snapshot" device, combining #1 and #2, which is the visible snapshot

   volume;

4) the "original" volume (which uses the device number used by the original

   source volume), whose table is replaced by a "snapshot-origin" mapping

   from device #1.

A fixed naming scheme is used, so with the following commands:

lvcreate -L 1G -n base volumeGroup

lvcreate -L 100M --snapshot -n snap volumeGroup/base

we'll have this situation (with volumes in above order):

# dmsetup table|grep volumeGroup

volumeGroup-base-real: 0 2097152 linear 8:19 384

volumeGroup-snap-cow: 0 204800 linear 8:19 2097536

volumeGroup-snap: 0 2097152 snapshot 254:11 254:12 P 16

volumeGroup-base: 0 2097152 snapshot-origin 254:11

# ls -lL /dev/mapper/volumeGroup-*

brw-------  1 root root 254, 11 29 ago 18:15 /dev/mapper/volumeGroup-base-real

brw-------  1 root root 254, 12 29 ago 18:15 /dev/mapper/volumeGroup-snap-cow

brw-------  1 root root 254, 13 29 ago 18:15 /dev/mapper/volumeGroup-snap

brw-------  1 root root 254, 10 29 ago 18:14 /dev/mapper/volumeGroup-base

Where to get sparse

~~~~~~~~~~~~~~~~~~~

With BK, you can just get it from

With git, you can just get it from

        bk://sparse.bkbits.net/sparse

        rsync://rsync.kernel.org/pub/scm/devel/sparse/sparse.git

and DaveJ has tar-balls at

Revised: 2000-Dec-05.

Again:   2002-Jul-06

Again:   2005-Sep-19

    NOTE:

  and deliver the data and status back. 

- Execution of an URB is inherently an asynchronous operation, i.e. the 

  usb_submit_urb(urb) call returns immediately after it has successfully queued 

  the requested action. 

  usb_submit_urb(urb) call returns immediately after it has successfully

  queued the requested action.

- Transfers for one URB can be canceled with usb_unlink_urb(urb) at any time. 

	void usb_free_urb(struct urb *urb)

You may not free an urb that you've submitted, but which hasn't yet been

returned to you in a completion callback.

You may free an urb that you've submitted, but which hasn't yet been

returned to you in a completion callback.  It will automatically be

deallocated when it is no longer in use.

1.4. What has to be filled in?

1.6. How to cancel an already running URB?

For an URB which you've submitted, but which hasn't been returned to

your driver by the host controller, call

There are two ways to cancel an URB you've submitted but which hasn't

been returned to your driver yet.  For an asynchronous cancel, call

	int usb_unlink_urb(struct urb *urb)

It removes the urb from the internal list and frees all allocated

HW descriptors. The status is changed to reflect unlinking. After 

usb_unlink_urb() returns with that status code, you can free the URB

with usb_free_urb().

HW descriptors. The status is changed to reflect unlinking.  Note

that the URB will not normally have finished when usb_unlink_urb()

returns; you must still wait for the completion handler to be called.

There is also an asynchronous unlink mode.  To use this, set the

the URB_ASYNC_UNLINK flag in urb->transfer flags before calling

usb_unlink_urb().  When using async unlinking, the URB will not

normally be unlinked when usb_unlink_urb() returns.  Instead, wait

for the completion handler to be called.

To cancel an URB synchronously, call

	void usb_kill_urb(struct urb *urb)

It does everything usb_unlink_urb does, and in addition it waits

until after the URB has been returned and the completion handler

has finished.  It also marks the URB as temporarily unusable, so

that if the completion handler or anyone else tries to resubmit it

they will get a -EPERM error.  Thus you can be sure that when

usb_kill_urb() returns, the URB is totally idle.

1.7. What about the completion handler?

The handler is of the following type:

	typedef void (*usb_complete_t)(struct urb *);

	typedef void (*usb_complete_t)(struct urb *, struct pt_regs *)

i.e. it gets just the URB that caused the completion call.

I.e., it gets the URB that caused the completion call, plus the

register values at the time of the corresponding interrupt (if any).

In the completion handler, you should have a look at urb->status to

detect any USB errors. Since the context parameter is included in the URB,

you can pass information to the completion handler. 

Note that even when an error (or unlink) is reported, data may have been

transferred.  That's because USB transfers are packetized; it might take

sixteen packets to transfer your 1KByte buffer, and ten of them might

have transferred succesfully before the completion is called.

have transferred succesfully before the completion was called.

NOTE:  ***** WARNING *****

Don't use urb->dev field in your completion handler; it's cleared

as part of giving urbs back to drivers.  (Addressing an issue with

ownership of periodic URBs, which was otherwise ambiguous.) Instead,

use urb->context to hold all the data your driver needs.

NOTE:  ***** WARNING *****

Also, NEVER SLEEP IN A COMPLETION HANDLER.  These are normally called

NEVER SLEEP IN A COMPLETION HANDLER.  These are normally called

during hardware interrupt processing.  If you can, defer substantial

work to a tasklet (bottom half) to keep system latencies low.  You'll

probably need to use spinlocks to protect data structures you manipulate

Interrupt transfers, like isochronous transfers, are periodic, and happen

in intervals that are powers of two (1, 2, 4 etc) units.  Units are frames

for full and low speed devices, and microframes for high speed ones.

Currently, after you submit one interrupt URB, that urb is owned by the

host controller driver until you cancel it with usb_unlink_urb().  You

may unlink interrupt urbs in their completion handlers, if you need to.

After a transfer completion is called, the URB is automagically resubmitted.

THIS BEHAVIOR IS EXPECTED TO BE REMOVED!!

Interrupt transfers may only send (or receive) the "maxpacket" value for

the given interrupt endpoint; if you need more data, you will need to

copy that data out of (or into) another buffer.  Similarly, you can't

queue interrupt transfers.

THESE RESTRICTIONS ARE EXPECTED TO BE REMOVED!!

Note that this automagic resubmission model does make it awkward to use

interrupt OUT transfers.  The portable solution involves unlinking those

OUT urbs after the data is transferred, and perhaps submitting a final

URB for a short packet.

The usb_submit_urb() call modifies urb->interval to the implemented interval

value that is less than or equal to the requested interval value.

In Linux 2.6, unlike earlier versions, interrupt URBs are not automagically

restarted when they complete.  They end when the completion handler is

called, just like other URBs.  If you want an interrupt URB to be restarted,

your completion handler must resubmit it.

S:	Maintained

I2C SUBSYSTEM

P:	Greg Kroah-Hartman

M:	greg@kroah.com

P:	Jean Delvare

M:	khali@linux-fr.org

L:	lm-sensors@lm-sensors.org

L:	fastboot@osdl.org

S:	Maintained

KPROBES

P:	Prasanna S Panchamukhi

M:	prasanna@in.ibm.com

P:	Ananth N Mavinakayanahalli

M:	ananth@in.ibm.com

P:	Anil S Keshavamurthy

M:	anil.s.keshavamurthy@intel.com

P:	David S. Miller

M:	davem@davemloft.net

L:	linux-kernel@vger.kernel.org

S:	Maintained

LANMEDIA WAN CARD DRIVER

P:	Andrew Stanley-Jones

M:	asj@lanmedia.com

			   your existing ./.config file.

	"make silentoldconfig"

			   Like above, but avoids cluttering the screen

			   with question already answered.

			   with questions already answered.

	NOTES on "make config":

	- having unnecessary drivers will make the kernel bigger, and can

   are installing a new kernel with the same version number as your

   working kernel, make a backup of your modules directory before you

   do a "make modules_install".

   In alternative, before compiling, edit your Makefile and change the

   "EXTRAVERSION" line - its content is appended to the regular kernel

   version.

   Alternatively, before compiling, use the kernel config option

   "LOCALVERSION" to append a unique suffix to the regular kernel version.

   LOCALVERSION can be set in the "General Setup" menu.

 - In order to boot your new kernel, you'll need to copy the kernel

   image (e.g. .../linux/arch/i386/boot/bzImage after compilation)