From: Marco Stornelli <marco.stornelli@gmail.com>
To: joern@lazybastard.org
Cc: sam@ravnborg.org, tim.bird@am.sony.com,
Arnd Bergmann <arnd@arndb.de>,
linux-fsdevel@vger.kernel.org, linux-embedded@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: I:Re: [PATCH 06/14] Pramfs: Include files
Date: Wed, 24 Jun 2009 08:30:49 +0200 [thread overview]
Message-ID: <2ea1731b0906232330u700e8bc0p7b0cafa83d8d2d5a@mail.gmail.com> (raw)
In-Reply-To: <4a4130db.0af6660a.48a9.ffffdace@mx.google.com>
> 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-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
parent reply other threads:[~2009-06-24 6:30 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <4a4130db.0af6660a.48a9.ffffdace@mx.google.com>]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2ea1731b0906232330u700e8bc0p7b0cafa83d8d2d5a@mail.gmail.com \
--to=marco.stornelli@gmail.com \
--cc=arnd@arndb.de \
--cc=joern@lazybastard.org \
--cc=linux-embedded@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sam@ravnborg.org \
--cc=tim.bird@am.sony.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).