linux-kernel - Re: [PATCH 08/16 v2] pramfs: headers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <AANLkTik+Vx8W1qXEZ=AqedRSj_D4-k70Xa4h-bnW2MRH@mail.gmail.com>
Date:	Wed, 10 Nov 2010 09:15:36 +0100
From:	Marco Stornelli <marco.stornelli@...il.com>
To:	Ryan Mallon <ryan@...ewatersys.com>
Cc:	Geert Uytterhoeven <geert@...ux-m68k.org>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	Linux Embedded <linux-embedded@...r.kernel.org>,
	Linux FS Devel <linux-fsdevel@...r.kernel.org>,
	Tim Bird <tim.bird@...sony.com>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH 08/16 v2] pramfs: headers

2010/11/9 Geert Uytterhoeven <geert@...ux-m68k.org>:
> On Tue, Nov 9, 2010 at 21:35, Ryan Mallon <ryan@...ewatersys.com> wrote:
>> You can still do all of those things without having a fixed endianess.
>> You just have to have one extra step of telling the external tools what
>> the endianess is. IMHO, it is better to have the overhead of the endian
>> conversion in the tools since it is less costly there than an the
>> embedded system.
>>
>> I'm just trying to understand why the fixed endianess rule cannot be
>> bent for such a specialised filesystem.
>
> When it was decided that filesystems should be fixed-endian and support for
> big-endian ext2 was dropped, the overhead of doing the fixed conversions was
> deetermined negligible due to compiler optimization.
> That was ages ago, and current embedded systems run circles around the
> machines of those days.
>
> Note that this is about metadata only. Actual file contents are always just
> byte streams.
>

I can add that the penalties in this case are  negligible due to the
compensation of the very fast access of the media. In addition, from
performance point of view I'm pretty happy (you can see the some
benchmark on the project web site).

Marco
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/