From: nyet <nyet@mrv.com>
To: Frans Meulenbroeks <fransmeulenbroeks@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Nye Liu <nyet@nyet.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] INITRAMFS: Add option to preserve mtime from INITRAMFS cpio images
Date: Thu, 04 Sep 2008 00:13:04 -0700 [thread overview]
Message-ID: <48BF8A80.50209@mrv.com> (raw)
In-Reply-To: <ac9c93b10809040011h19b70715ge2ba06372f1b0fe0@mail.gmail.com>
Frans Meulenbroeks wrote:
> 2008/9/4 Nye Liu <nyet@mrv.com>:
>
>> On Wed, Sep 03, 2008 at 03:22:31PM -0700, Andrew Morton wrote:
>>
>>>> From: Nye Liu <nyet@nyet.org>
>>>>
>>>> When unpacking the cpio into the initramfs, mtimes are not preserved by
>>>> default. This patch adds an INITRAMFS_PRESERVE_MTIME option that allows mtimes
>>>> stored in the cpio image to be used when constructing the initramfs. For
>>>> embedded applications that run exclusively out of the initramfs, this is
>>>> invaluable.
>>>>
>>> Why is it "invlauable". Please explain this value in full detail -
>>> it's the whole reason for merging the patch!
>>>
>> When building embedded application initramfs images, its nice to know
>> when the files were actually created during the build process - that
>> makes it easier to see what files were modified when so we can compare
>> the files that are being used on the image with the files used during
>> the build process. This might help (for example) to determine if the
>> target system has all the updated files you expect to see w/o having to
>> check MD5s etc.
>>
>
> Hm.
>
> "Invaluable" != "nice to know".
>
> What worries me is that this code is executed at boot time (when
> populating the ramfs).
> For embedded systems a fast boot time is often important.
> I admit that the net effect of this on boot time is marginal (but some
> might consider having mtime a marginal benefit), and 100 cents also
> make a dollar, so my suggestion would be to either reject this patch
> or make it optional (e.g. depending on some debug config flag).
>
> Best regards, Frans.
>
An earlier rev patch made it optional. I can resubmit of course.
next prev parent reply other threads:[~2008-09-04 7:13 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-05 19:52 [PATCH] INITRAMFS: Add option to preserve mtime from INITRAMFS cpio images Nye Liu
2008-08-16 8:58 ` Andrew Morton
2008-09-03 20:29 ` Nye Liu
2008-09-03 22:22 ` Andrew Morton
2008-09-03 22:31 ` Nye Liu
2008-09-03 22:36 ` Andrew Morton
2008-09-04 7:11 ` Frans Meulenbroeks
2008-09-04 7:13 ` nyet [this message]
2008-09-04 23:08 ` Krzysztof Halasa
2008-09-03 22:41 ` Nye Liu
2008-09-03 22:48 ` Andrew Morton
2008-09-03 22:53 ` Nye Liu
2008-09-03 22:54 ` Nye Liu
2008-09-03 23:04 ` Nye Liu
2008-09-03 23:19 ` Andrew Morton
2008-09-03 23:30 ` Nye Liu
[not found] ` <20080903164144.27c94bae.akpm@linux-foundation.org>
2008-09-04 1:40 ` [PATCH] INITRAMFS: Preserve " Nye Liu
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=48BF8A80.50209@mrv.com \
--to=nyet@mrv.com \
--cc=akpm@linux-foundation.org \
--cc=fransmeulenbroeks@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=nyet@nyet.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.