linux-toradex.git/lib/Makefile, branch v2.6.34.15

crypto: Move md5_transform to lib/md5.c

2012-05-17T15:21:27+00:00

commit bc0b96b54a21246e377122d54569eef71cec535f upstream.

We are going to use this for TCP/IP sequence number and fragment ID
generation.

Signed-off-by: David S. Miller 
Signed-off-by: Paul Gortmaker

block: Fix overrun in lcm() and move it to lib

2010-03-15T11:47:59+00:00

lcm() was defined to take integer-sized arguments.  The supplied
arguments are multiplied, however, causing us to overflow given
sufficiently large input.  That in turn led to incorrect optimal I/O
size reporting in some cases (RAID over RAID).

Switch lcm() over to unsigned long similar to gcd() and move the
function from blk-settings.c to lib.

Signed-off-by: Martin K. Petersen 
Signed-off-by: Jens Axboe

Revert "lib: build list_sort() only if needed"

2010-03-07T17:54:44+00:00

This reverts commit a069c266ae5fdfbf5b4aecf2c672413aa33b2504.

It turns ou that not only was it missing a case (XFS) that needed it,
but perhaps more importantly, people sometimes want to enable new
modules that they hadn't had enabled before, and if such a module uses
list_sort(), it can't easily be inserted any more.

So rather than add a "select LIST_SORT" to the XFS case, just leave it
compiled in.  It's not all _that_ big, after all, and the inconvenience
isn't worth it.

Requested-by: Alexey Dobriyan 
Cc: Christoph Hellwig 
Cc: Don Mullis 
Cc: Andrew Morton 
Cc: Dave Chinner 
Signed-off-by: Linus Torvalds

Merge git://git.kernel.org/pub/scm/linux/kernel/git/joern/logfs

2010-03-06T21:18:03+00:00

* git://git.kernel.org/pub/scm/linux/kernel/git/joern/logfs:
  [LogFS] Change magic number
  [LogFS] Remove h_version field
  [LogFS] Check feature flags
  [LogFS] Only write journal if dirty
  [LogFS] Fix bdev erases
  [LogFS] Silence gcc
  [LogFS] Prevent 64bit divisions in hash_index
  [LogFS] Plug memory leak on error paths
  [LogFS] Add MAINTAINERS entry
  [LogFS] add new flash file system

Fixed up trivial conflict in lib/Kconfig, and a semantic conflict in
fs/logfs/inode.c introduced by write_inode() being changed to use
writeback_control' by commit a9185b41a4f84971b930c519f0c63bd450c4810d
("pass writeback_control to ->write_inode")

lib: build list_sort() only if needed

2010-03-06T19:26:35+00:00

Build list_sort() only for configs that need it -- those that don't save
~581 bytes (i386).

Signed-off-by: Don Mullis 
Cc: Dave Airlie 
Cc: Andi Kleen 
Cc: Dave Chinner 
Cc: Artem Bityutskiy 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

lib: Introduce generic list_sort function

2010-01-13T05:02:00+00:00

There are two copies of list_sort() in the tree already, one in the DRM
code, another in ubifs.  Now XFS needs this as well.  Create a generic
list_sort() function from the ubifs version and convert existing users
to it so we don't end up with yet another copy in the tree.

Signed-off-by: Dave Chinner 
Acked-by: Dave Airlie 
Acked-by: Artem Bityutskiy 
Signed-off-by: Linus Torvalds

Add LZO compression support for initramfs and old-style initrd

2010-01-11T17:34:05+00:00

Signed-off-by: Albin Tonnerre 
Tested-by: Wu Zhangjin 
Acked-by: "H. Peter Anvin" 
Cc: Ingo Molnar 
Cc: Thomas Gleixner 
Tested-by: Russell King 
Acked-by: Russell King 
Cc: Ralf Baechle 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[LogFS] add new flash file system

2009-11-20T19:13:39+00:00

This is a new flash file system. See
Documentation/filesystems/logfs.txt

Signed-off-by: Joern Engel

The DRBD driver

2009-10-01T19:17:49+00:00

Signed-off-by: Philipp Reisner 
Signed-off-by: Lars Ellenberg

lib: flexible array implementation

2009-07-30T02:10:36+00:00

Once a structure goes over PAGE_SIZE*2, we see occasional allocation
failures.  Some people have chosen to switch over to things like vmalloc()
that will let them keep array-like access to such a large structures.
But, vmalloc() has plenty of downsides.

Here's an alternative.  I think it's what Andrew was suggesting here:

	http://lkml.org/lkml/2009/7/2/518

I call it a flexible array.  It does all of its work in PAGE_SIZE bits, so
never does an order>0 allocation.  The base level has
PAGE_SIZE-2*sizeof(int) bytes of storage for pointers to the second level.
 So, with a 32-bit arch, you get about 4MB (4183112 bytes) of total
storage when the objects pack nicely into a page.  It is half that on
64-bit because the pointers are twice the size.  There's a table detailing
this in the code.

There are kerneldocs for the functions, but here's an
overview:

flex_array_alloc() - dynamically allocate a base structure
flex_array_free() - free the array and all of the
		    second-level pages
flex_array_free_parts() - free the second-level pages, but
			  not the base (for static bases)
flex_array_put() - copy into the array at the given index
flex_array_get() - copy out of the array at the given index
flex_array_prealloc() - preallocate the second-level pages
			between the given indexes to
			guarantee no allocs will occur at
			put() time.

We could also potentially just pass the "element_size" into each of the
API functions instead of storing it internally.  That would get us one
more base pointer on 32-bit.

I've been testing this by running it in userspace.  The header and patch
that I've been using are here, as well as the little script I'm using to
generate the size table which goes in the kerneldocs.

	http://sr71.net/~dave/linux/flexarray/

[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: Dave Hansen 
Reviewed-by: KAMEZAWA Hiroyuki 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds