> What about simply deep-sixing cramfs and replacing it with squashfs or
> something else?
I think this is the long term solution. Cramfs isn't a very beautiful
filesystem. It's a good candidate for removal. However, there are still some
distributions that use cramfs for initrds. So removing it
Andi Drebes wrote:
Indeed, this is the problem. The readme file fs/cramfs/README states:
"One part of that is addressing endianness. The two options here are
`always use little-endian' (like ext2fs) or `writer chooses
endianness; kernel adapts at runtime'. Little-endian wins because of
code s
> > Endian-independent code is slower than wrong-endian code, because of the
> > necessary conditionals. Thus, you DO NOT WANT this(*).
>
> I'd prefer not to have it either. But a someone (pinhead) was smart
> enough not to define an endianess for cramfs from the beginning we're
> stuck with it
Christoph Hellwig wrote:
On Fri, Nov 09, 2007 at 05:03:01PM -0800, H. Peter Anvin wrote:
Endian-independent code is slower than wrong-endian code, because of the
necessary conditionals. Thus, you DO NOT WANT this(*).
I'd prefer not to have it either. But a someone (pinhead) was smart
enough
On Fri, Nov 09, 2007 at 05:03:01PM -0800, H. Peter Anvin wrote:
> Endian-independent code is slower than wrong-endian code, because of the
> necessary conditionals. Thus, you DO NOT WANT this(*).
I'd prefer not to have it either. But a someone (pinhead) was smart
enough not to define an endiane
Christoph Hellwig wrote:
On Wed, Nov 07, 2007 at 09:51:48PM +0100, Andi Drebes wrote:
Hi!
I would suggest you to use squashfs instead of cramfs.
First, it's newer, it's better, it's actively developed, it doesn't have any
limits like the bad cramfs.
I'm developing a new linux based firmware f
Hi!
> Making cramfs endianess-independent shouldn't be much work. Take a look
> at the helpers in fs/ufs/swab.h and use them for every ondisk access in
> cramfs. Drop me a not if you need some help.
I already started working on this feature some time ago. I think I am able to
mount cramfs image
On Wed, Nov 07, 2007 at 09:51:48PM +0100, Andi Drebes wrote:
> Hi!
>
> > I would suggest you to use squashfs instead of cramfs.
> > First, it's newer, it's better, it's actively developed, it doesn't have any
> > limits like the bad cramfs.
> I'm developing a new linux based firmware for my route
Hi!
> I would suggest you to use squashfs instead of cramfs.
> First, it's newer, it's better, it's actively developed, it doesn't have any
> limits like the bad cramfs.
I'm developing a new linux based firmware for my router which uses cramfs.
Switching to squashfs still needs some time. Meanwh
> I'm currently trying to enable the cramfs to mount filesystems with a
> different endianness.
I would suggest you to use squashfs instead of cramfs.
First, it's newer, it's better, it's actively developed, it doesn't have any
limits like the bad cramfs.
Moreover, it currently supports both e
Hi!
I'm currently trying to enable the cramfs to mount filesystems with a
different endianness. All I have is an intel compatible machine that produces
cramfs images in little endian format. I found a modified version of mkcramfs
that is able to produce images in big endian mode. Unfortunately i
11 matches
Mail list logo
