From: Andrew Morton <akpm@linux-foundation.org>
To: Nye Liu <nyet@mrv.com>
Cc: nyet@nyet.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] INITRAMFS: Add option to preserve mtime from INITRAMFS cpio images
Date: Wed, 3 Sep 2008 15:36:37 -0700 [thread overview]
Message-ID: <20080903153637.0e9dc471.akpm@linux-foundation.org> (raw)
In-Reply-To: <20080903223114.GA9456@mrv.com>
On Wed, 3 Sep 2008 15:31:14 -0700
Nye Liu <nyet@mrv.com> wrote:
> 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.
>
> In our environment, the whole system runs off the initramfs partition,
> and seeing the modified times of the shared libraries (for example)
> helps us find bugs that may have been introduced by the build system
> incorrectly propogating outdated shared libraries into the image.
>
> Similarly, many of the initializion/configuration files in /etc
> might be dynamically built by the build system, and knowing when
> they were modified helps us sanity check whether the target system
> has the "latest" files etc.
>
> Finally, we might use last modified times to determine whether a
> hot fix should be applied or not to the running ramfs.
>
Thanks, I updated the changelog.
> > gargh. Why does this work? It's normally a big fail to pass a kernel
> > address into a system call. I guess we're running under KERNEL_DS here
> > and getname() and strncpy_from_user() did the right thing.
> >
> > On what CPU architecture was this tested?
> >
> > Wouldn't it be simpler to put a timespec into struct dir_entry then go
> > direct to do_utimes() here?
> >
Did you see this stuff?
next prev parent reply other threads:[~2008-09-03 22:36 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 [this message]
2008-09-04 7:11 ` Frans Meulenbroeks
2008-09-04 7:13 ` nyet
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=20080903153637.0e9dc471.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nyet@mrv.com \
--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.