[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <48BF8A80.50209@mrv.com>
Date: Thu, 04 Sep 2008 00:13:04 -0700
From: nyet <nyet@....com>
To: Frans Meulenbroeks <fransmeulenbroeks@...il.com>
CC: Andrew Morton <akpm@...ux-foundation.org>, Nye Liu <nyet@...t.org>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] INITRAMFS: Add option to preserve mtime from INITRAMFS
cpio images
Frans Meulenbroeks wrote:
> 2008/9/4 Nye Liu <nyet@....com>:
>
>> On Wed, Sep 03, 2008 at 03:22:31PM -0700, Andrew Morton wrote:
>>
>>>> From: Nye Liu <nyet@...t.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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists