> 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