LKML Archive on
help / color / mirror / Atom feed
From: Rob Landley <>
To:, Victor Kamensky <>
Cc: Taras Kondratiuk <>,
	Al Viro <>, Arnd Bergmann <>,
	Mimi Zohar <>,
	Jonathan Corbet <>,
	James McMechan <>,,,,,
Subject: Re: [PATCH v3 01/15] Documentation: add newcx initramfs format description
Date: Sat, 17 Feb 2018 11:32:51 -0600	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On 02/16/2018 06:00 PM, wrote:
> Introducing new, incompatible data formats is an inherently *very*
> costly operation; unfortunately many engineers don't seem to have a good grip
> of just *how* expensive it is (see "silly embedded nonsense hacks", "too
> little, too soon".)

So your argument is we should use the _existing_ cpio format that supports xattrs?

You keep bringing up the embedded world as a thing you don't understand and is
thus bad. I remember when you dismissed "I would like to constrain my
cross-compiling dependencies to a minimal set" as a... what did you call it, a
silly academic exercise? (Googles...)

> Cpio itself is a great horror show of just how bad this gets:

That's not what you said last time?

> Introducing a new incompatible data format without strong justification

Here's you suggesting a new format when initramfs first went in, because you
disliked _both_ tar and cpio:

Seriously, there is a "why cpio rather than tar" section of
with links to the messages. (www.uwsg became lkml in the links, I should submit
a patch fixing that, it redirected 6 months ago...)

We've _had_ this argument already. You are not bringing up _new_ arguments.

This patch set is because people want xattrs in initramfs. I still don't
personally understand why they want this, but they do. We need to still support
the existing file format for the forseeable future, and we might as well fix
y2038 while we're there (treating it as unsigned buys us a lot of decades, but
as long as we're bumping the version number anyway...).

Otherwise it tries to be the minimal set of changes to get us there. (My first
stab at this was dealing with sparse files, but runs of zeroes gzip pretty well
and tmpfs could always make itself sparse after the fact...)

> Doing it under the non-justification of expedience ("oh, we can share most>
> of the code") is aggravated engineering malpractice.

Coming from the guy who added perl as a build dependency to every project he
maintained simultaneously (the linux kernel, your bootloader, klibc), that seems
a lot more like an opinion than an objective metric.

> It is entirely possible that the modern posix tar/pax format is too complex

In the link above you declared it too complex in 2001. Partly because the gnu
tar and pax formats aren't really the same format.

> to be practical in this case – that would be justifying a new format.  But
> then you are taking the fundamental cost of breakage, and then the new format
> definitely should not be replicating known defects of another format and
> without at least some thought about how to avoid it in the future.

Didn't Linus flame more than one developer for ripping things out and replacing
them with a new untested thing rather than leaving a trail of breadcrumbs from a
known working thing to another known working thing? Or has the right way to do
it changed since the 2.5 development cycle?

Strangely the poor souls suffering under the burden of cpio to use initramfs
today haven't been screaming out their agony in a detectable way. (They're mad
the kernel doesn't give better feedback about why init failed to launch and it
either paniced or fell through to the fallback ROOT=, my patch to make
devtmpfs_mount work for initramfs was trying to fix the "you pointed the kernel
at a root filesystem directory which it cpio'd up but there was /dev/console in
it so your init has no stdin/stdout/stderr and dies immediately because of it"
problem. And the recent thread about "please don't add a third knob to make
initramfs be tmpfs instead of ramfs" was another corner case of that). And I
have half an INITRAMFS_VERBOSE patch around here somewhere to printk() a lot
more status (and I need to update the initramfs documentation I wrote to help
people have an easier time using it...)

But that's not about archive format. That's kernel userspace bringup being
persnickety. The silent majority you speak for on this archive format issue is
pretty darn silent.

Was this recorded as a problem for you before somebody suggested changing it? I
tend to be public about
and collect links to other people's concerns when I notice...

Or is this just your opinion?


  parent reply	other threads:[~2018-02-17 17:33 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-16 20:33 [PATCH v3 00/15] extend initramfs archive format to support xattrs Taras Kondratiuk
2018-02-16 20:33 ` [PATCH v3 01/15] Documentation: add newcx initramfs format description Taras Kondratiuk
2018-02-16 20:59   ` H. Peter Anvin
2018-02-16 21:25     ` Rob Landley
2018-02-16 21:47       ` Victor Kamensky
2018-02-17  0:00         ` hpa
2018-02-17 10:04           ` Taras Kondratiuk
2018-02-17 17:32           ` Rob Landley [this message]
2018-02-18  0:15     ` Mimi Zohar
2018-02-18  0:24       ` hpa
2018-02-18  0:26       ` hpa
2018-02-18  0:47         ` Mimi Zohar
2018-02-16 20:33 ` [PATCH v3 02/15] initramfs: replace states with function pointers Taras Kondratiuk
2018-02-16 20:33 ` [PATCH v3 03/15] initramfs: store file name in name_buf Taras Kondratiuk
2018-02-16 20:33 ` [PATCH v3 04/15] initramfs: remove unnecessary symlinks processing shortcut Taras Kondratiuk
2018-02-16 20:33 ` [PATCH v3 05/15] initramfs: move files creation into separate state Taras Kondratiuk
2018-02-16 20:33 ` [PATCH v3 06/15] initramfs: separate reading cpio method from header Taras Kondratiuk
2018-02-16 20:33 ` [PATCH v3 07/15] initramfs: split header layout information from parsing function Taras Kondratiuk
2018-02-16 20:33 ` [PATCH v3 08/15] initramfs: add newcx format Taras Kondratiuk
2018-02-16 20:33 ` [PATCH v3 09/15] initramfs: set extended attributes Taras Kondratiuk
2018-02-16 20:33 ` [PATCH v3 10/15] gen_init_cpio: move header formatting into function Taras Kondratiuk
2018-02-16 20:33 ` [PATCH v3 11/15] gen_init_cpio: add newcx format Taras Kondratiuk
2018-02-16 20:33 ` [PATCH v3 12/15] gen_init_cpio: set extended attributes for " Taras Kondratiuk
2018-02-16 20:33 ` [PATCH v3 12/14] add -x option to enable " Taras Kondratiuk
2018-02-16 20:33 ` [PATCH v3 13/15] " Taras Kondratiuk
2018-02-16 20:33 ` [PATCH v3 13/14] selinux: allow setxattr on rootfs so initramfs code can set them Taras Kondratiuk
2018-02-16 20:33 ` [PATCH v3 14/15] " Taras Kondratiuk
2018-02-20 19:01   ` Stephen Smalley
2018-03-11  3:07     ` Victor Kamensky
2018-03-20 16:33       ` [Non-DoD Source] " Stephen Smalley
2018-02-16 20:33 ` [PATCH v3 14/14] selinux: delay sid population for rootfs till init is complete Taras Kondratiuk
2018-02-16 20:33 ` [PATCH v3 15/15] " Taras Kondratiuk
2018-02-20 18:56   ` Stephen Smalley
2018-03-07 16:51     ` Rob Landley
2018-03-07 17:26       ` Victor Kamensky
2018-03-11  3:08     ` Victor Kamensky
2018-03-20 16:30       ` [Non-DoD Source] " Stephen Smalley

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \
    --subject='Re: [PATCH v3 01/15] Documentation: add newcx initramfs format description' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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).