On Tue, 23 June 2009 19:38:33 +0200, Marco wrote: > > dd? You haven't got any device file to have a dump. I think we're going > a bit out of scope. I had some doubt to support rootfs in pram and after > some feedback and the comments of this review I think I'll remove it > from the next release (to understand some aspects of this fs with the > kernel community was my main goal for this review). I agree to use the > native endian. As I said the important thing is that if an user want to > use it in a 64bit environment then the fs must work well and then it > must be designed to support even this situation, I think it's obvious. Glancing at the discussion with Pawel, I see two paths to follow. One is to turn pramfs into a full-features all-round general-purpose filesystem with mkfs, fsck, xattr and any number of additional features. That way lies doom, as you would compete against ext2+xip and have little new to offer. The other path is to make/keep pramfs as simple as possible for comparatively specialized purposes, like flight recorder data and dump information. Main selling point here is the amount of vulnerable code in the total package. ext2 + block layer + vfs helpers is relatively large and many things may go wrong in a panic situation. So I agree with you that many things expected from general purpose filesystems simply don't apply to pramfs. Moving mkfs into the kernel is a fair tradeoff, when the required code is small. Endianness is a different case imo. dd may not work, but a jtag probe will happily get you the dump to your development machine. And even within the same box you can have more than one architecture and endianness. http://www.top500.org/system/9707 will show you one such beast, which happens to have the top bragging rights at the moment. I don't want to endorse such strange beasts, but there is no good reason not to support reading the ppc-written fs from the opteron. In fact, there is no reason full stop. Jörn -- Beware of bugs in the above code; I have only proved it correct, but not tried it. -- Donald Knuth -- 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
