[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AANLkTin_r58efRXM609hT_nc-oO_ojPHzsgOU92bEI9s@mail.gmail.com>
Date: Thu, 10 Jun 2010 13:42:55 -0600
From: Brian Gordon <legerde@...il.com>
To: Massimiliano Galanti <massiblue@...ero.it>
Cc: Chris Friesen <cfriesen@...tel.com>, linux-kernel@...r.kernel.org,
Andi Kleen <andi@...stfloor.org>
Subject: Re: Aerospace and linux
Sorry, I take it back. This wont work for me because I wont have
NOR. Also, I only want the "in-place" to apply to read-only pages.
This looks like all reads and writes get passed to the underlying
storage and I can't suffer flash page erase/writes to update a
variable. :) The device will wear out and meaningful work would be
starved.
On Thu, Jun 10, 2010 at 1:37 PM, Brian Gordon <legerde@...il.com> wrote:
> Yes. Thats exactly what I am looking for. Even if there is a speed
> penalty, I wouldn't mind so much. However wikipedia says that XIP is
> filesystem dependent and im stuck with FAT32 or NTFS. Wikipedia
> claims NTFS can do XIP. Is this true under linux?
>
> On Thu, Jun 10, 2010 at 1:23 PM, Massimiliano Galanti
> <massiblue@...ero.it> wrote:
>>
>>> What about .ro and .text sections of an executable? I would think
>>> kernel support for that would be required. If its application data,
>>> then all sorts of things are possible like you described. Ive also
>>> seen critical ram variables be stored in triplicate and then
>>> compared/voted just to ensure no silent SEU corruption.
>>
>> Maybe slightly off topic but... if flash is safer than ram, what about using
>> XIP (where possible, e.g. on NORs)? That would not put .data sections into
>> ram, at least.
>>
>> --
>> Massimiliano
>>
>
--
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/
Powered by blists - more mailing lists