> 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. > I quite agree, but I'd like to say that it was _not_ my intention to submit a general-purpose fs comparable with ext2 or ext3. > 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 > Mmm....Jtag dump makes more sense, ok in the next release I rework the layout to have an independent endianess layout. 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
