--- Eric Paris <[EMAIL PROTECTED]> wrote:
>
> On Fri, 2007-11-09 at 14:46 -0800, Casey Schaufler wrote:
> > --- Eric Paris <[EMAIL PROTECTED]> wrote:
> >
> > > Adds security_get_sb_mnt_opts, security_set_sb_mnt_opts, and
> > > security_clont_sb_mnt_opts to the LSM and to SELinux. This will all
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
