Pavel Machek wrote: > On Mon 2009-06-22 14:50:01, Tim Bird wrote: >> Pavel Machek wrote: >>>> block of fast non-volatile RAM that need to access data on it using a >>>> standard filesytem interface." >>> Turns a block of fast RAM into 13MB/sec disk. Hmm. I believe you are >>> better with ext2. >> Not if you want the RAM-based filesystem to persist over a kernel >> invocation. > > Yes, you'll need to code Persistent, RAM-based _block_device_. > Pavel First of all I have to say that I'd like to update the site and make it clearer but at the moment it's not possible because I'm not the admin and I've already asked to the sourceforge support to have this possibility. About the comments: sincerely I don't understand the comments. We have *already* a fs that takes care to remap a piace of ram (ram, sram, nvram, etc.), takes care of caching problems, takes care of write protection, takes care to be "persistent", can use xip and it's my intention to add in the next future other features like acl, xattr and so on. You are talked about journaling. This schema works well for a disk, but what about a piece of ram? What about a crazy kernel that write in that area for a bug? Do you remember for example the e1000e bug? It's not casual that this fs use an hw protection schema. I mean, this fs is not only a "yet another fs", but a fs born with a specific target. So I think modifying a ramdisk to have these behaviors isn't a little modification. Marco -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
