On Mon, 22 June 2009 20:31:10 +0100, Chris Simmonds wrote:
I disagree: that adds an unnecessary overhead for those architectures
where the cpu byte order does not match the data structure ordering. I
think the data structures should be native endian and when mkpramfs is
written it can
On Mon, 22 June 2009 23:20:39 +0100, David Woodhouse wrote:
On Mon, 2009-06-22 at 23:41 +0200, Jörn Engel wrote:
Four loops doing the same increment with different data types: long,
u64, we32 (wrong-endian) and we64. Compile with _no_ optimizations.
That's a bit of a poor test
On Sun, 7 December 2008 23:32:32 +, Phillip Lougher wrote:
Currently, as mentioned above, Squashfs decompresses into a single
contiguous output buffer. But, due to the linux kernel mailing list's
dislike of vmalloc, this is being changed.
Don't blame lkml, blame Intel and IBM. Back
On Mon, 8 December 2008 21:47:37 +, Phillip Lougher wrote:
Yes, I'm aware of the issues with vmalloc on older hardware.
It's not even limited to older hardware. Blue Gene supercomputers are
large clusters of ppc440 machines. Iirc each node consists of two 32bit
cpus and up to 4GB of RAM.
On Fri, 31 October 2008 04:43:46 +, Phillip Lougher wrote:
Simplicity and speed is extremely important. The
squashfs_metadata_read() wrapper around the cache is designed to step
through the metadata a structure at a time (20 or so bytes), updating
the read position in the metadata
On Wed, 29 October 2008 01:49:56 +, Phillip Lougher wrote:
+/*
+ * Blocks in Squashfs are compressed. To avoid repeatedly decompressing
+ * recently accessed data Squashfs uses two small metadata and fragment
caches.
+ *
+ * This file implements a generic cache implementation used for
On Tue, 21 October 2008 12:14:26 -0400, David P. Quigley wrote:
On Fri, 2008-10-17 at 18:53 +0200, Jörn Engel wrote:
None of the comments below are a reason against mainline inclusion, imo.
They should get handled, but whether that happens before or after a
merge doesn't really matter
None of the comments below are a reason against mainline inclusion, imo.
They should get handled, but whether that happens before or after a
merge doesn't really matter.
On Fri, 17 October 2008 16:42:50 +0100, Phillip Lougher wrote:
+#include linux/squashfs_fs.h
+#include
On Fri, 17 October 2008 16:42:50 +0100, Phillip Lougher wrote:
Codewise all of the packed bit-fields and the swap macros have been removed in
favour of aligned structures and in-line swapping using leXX_to_cpu(). The
code has also been extensively restructured, reformatted to kernel coding
On Thu, 9 October 2008 18:21:51 +0300, Adrian Bunk wrote:
The building blocks that would be useful are IMHO:
- a make target that generates a report for one kernel
(like the checkstack or export_report targets)
- a script that compares two such reports and outputs the
size differences
On Tue, 2 September 2008 09:44:19 -0700, Jared Hulbert wrote:
How is one expected to read those last 4 bytes of a loopbacked file?
Are they unreadable? We can add the padding. I am just wondering if
this is a bug or a known limitation in the loopback handling or if
there is a different
On Tue, 17 June 2008 11:23:18 -0700, Tim Bird wrote:
I'm not that happy using an ioctl for this trigger. What is
the preferred method of activating a kernel feature like this?
I presume something in /proc or /sys, but I'm not sure.
I personally would be unhappy with any kind of interface
On Tue, 17 June 2008 12:52:22 -0700, Tim Bird wrote:
Jörn Engel wrote:
On Tue, 17 June 2008 11:23:18 -0700, Tim Bird wrote:
I'm not that happy using an ioctl for this trigger. What is
the preferred method of activating a kernel feature like this?
I presume something in /proc or /sys
On Tue, 17 June 2008 12:55:31 -0700, Tim Bird wrote:
Sorry - I responded too quickly. I'm not sure I follow the
original suggestion. How would I call the open function of
a module that is not initialized yet?
Hmm, good point. I guess that suggestion has just failed the reality
test.
Jörn
On Fri, 13 June 2008 14:10:29 -0700, Tim Bird wrote:
Maybe I should just be grateful for any ccache hits I get.
ccache's usefulness depends on your workload. If you make a change to
include/linux/fs.h, close to 100% of the kernel is rebuilt, with or
without ccache. But when you revert that
On Tue, 10 June 2008 12:41:54 -0700, Tim Bird wrote:
Delivery-date: Tue, 10 Jun 2008 21:44:08 +0200
From: Tim Bird [EMAIL PROTECTED]
To: linux-embedded linux-embedded@vger.kernel.org
CC: linux kernel [EMAIL PROTECTED]
Subject: [PATCH] add diffconfig utility
Neat. But I have one nagging
16 matches
Mail list logo
