Linux filesystem development
 help / color / mirror / Atom feed
From: David Disseldorp <ddiss@suse.de>
To: Randy Dunlap <rdunlap@infradead.org>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>,
	Christian Brauner <brauner@kernel.org>,
	linux-fsdevel@vger.kernel.org, linux-doc@vger.kernel.org
Subject: Re: [PATCH] docs: initramfs: update compression and mtime descriptions
Date: Mon, 31 Mar 2025 17:49:51 +1100	[thread overview]
Message-ID: <20250331174951.7818afb1.ddiss@suse.de> (raw)
In-Reply-To: <39c91e20-94b2-4103-8654-5a7bbb8e1971@infradead.org>

Thanks for the feedback, Randy...

On Sun, 30 Mar 2025 22:13:19 -0700, Randy Dunlap wrote:

> Hi,
> 
> On 3/30/25 10:03 PM, David Disseldorp wrote:
> > Update the document to reflect that initramfs didn't replace initrd
> > following kernel 2.5.x.
> > The initramfs buffer format now supports many compression types in
> > addition to gzip, so include them in the grammar section.
> > c_mtime use is dependent on CONFIG_INITRAMFS_PRESERVE_MTIME.
> > 
> > Signed-off-by: David Disseldorp <ddiss@suse.de>
> > ---
> >  .../early-userspace/buffer-format.rst         | 30 ++++++++++++-------
> >  1 file changed, 19 insertions(+), 11 deletions(-)
> > 
> > diff --git a/Documentation/driver-api/early-userspace/buffer-format.rst b/Documentation/driver-api/early-userspace/buffer-format.rst
> > index 7f74e301fdf35..cb31d617729c5 100644
> > --- a/Documentation/driver-api/early-userspace/buffer-format.rst
> > +++ b/Documentation/driver-api/early-userspace/buffer-format.rst
> > @@ -4,20 +4,18 @@ initramfs buffer format
> >  
> >  Al Viro, H. Peter Anvin
> >  
> > -Last revision: 2002-01-13
> > -
> > -Starting with kernel 2.5.x, the old "initial ramdisk" protocol is
> > -getting {replaced/complemented} with the new "initial ramfs"
> > -(initramfs) protocol.  The initramfs contents is passed using the same
> > -memory buffer protocol used by the initrd protocol, but the contents
> > +With kernel 2.5.x, the old "initial ramdisk" protocol was complemented
> > +with an "initial ramfs" protocol.  The initramfs contents is passed  
> 
>                                                              are passed
> 
> > +using the same memory buffer protocol used by initrd, but the contents
> >  is different.  The initramfs buffer contains an archive which is  
> 
>   are different.

I've not really changed those sentences with this patch, so I don't mind
if they stay as is, or switch "contents" to "content" or "is" to "are".

> >  expanded into a ramfs filesystem; this document details the format of
> >  the initramfs buffer format.  
> 
> Don't use "format" 2 times above.

This is also not changed by the patch. I'm happy to send a v2 or have
these clean-ups squashed in when applied. Will leave it up to the
maintainers.

  reply	other threads:[~2025-03-31  6:50 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-31  5:03 [PATCH] docs: initramfs: update compression and mtime descriptions David Disseldorp
2025-03-31  5:13 ` Randy Dunlap
2025-03-31  6:49   ` David Disseldorp [this message]
2025-03-31 15:33     ` Randy Dunlap
2025-04-01 10:40     ` Christian Brauner

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=20250331174951.7818afb1.ddiss@suse.de \
    --to=ddiss@suse.de \
    --cc=brauner@kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=rdunlap@infradead.org \
    --cc=viro@zeniv.linux.org.uk \
    /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