From: Richard Weinberger <richard@nod.at>
To: Helen Koike <helen.koike@collabora.com>, keescook@chromium.org
Cc: dm-devel@redhat.com, agk@redhat.com, snitzer@redhat.com,
linux-kernel@vger.kernel.org, enric.balletbo@collabora.com,
wad@chromium.org, linux-doc@vger.kernel.org,
linux-lvm@redhat.com, kernel@collabora.com
Subject: Re: [PATCH v10 0/2] dm: boot a mapped device without an initramfs
Date: Sat, 03 Nov 2018 10:10:08 +0100 [thread overview]
Message-ID: <3624012.MiIzIq7dko@blindfold> (raw)
In-Reply-To: <20181103035341.16893-1-helen.koike@collabora.com>
Helen,
Am Samstag, 3. November 2018, 04:53:39 CET schrieb Helen Koike:
> As mentioned in the discussion from the previous version of this patch, Android
> and Chrome OS do not use initramfs mostly due to boot time and size liability.
Do you have numbers on that?
I understand that using something like dracut with systemd inside is not what you
want from a boot time point of view.
But having an initramfs embedded into the kernel image which contains only a single
static linked binary can be *very* small and fast.
If you invest a little more time, you don't even need a libc, just fire up some
syscalls to setup your dm. I use this technique regularly on deeply embedded systems
to setup non-trivial UBIFS/crypto stuff.
Want I'm trying to say, before adding ad-hoc a feature to the kernel, we should be
very sure that there is no other way to solve this in a sane manner.
We have initramfs support for reasons.
Thanks,
//richard
WARNING: multiple messages have this Message-ID (diff)
From: Richard Weinberger <richard@nod.at>
To: Helen Koike <helen.koike@collabora.com>, keescook@chromium.org
Cc: wad@chromium.org, snitzer@redhat.com, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, dm-devel@redhat.com,
linux-lvm@redhat.com, enric.balletbo@collabora.com,
kernel@collabora.com, agk@redhat.com
Subject: Re: [linux-lvm] [PATCH v10 0/2] dm: boot a mapped device without an initramfs
Date: Sat, 03 Nov 2018 10:10:08 +0100 [thread overview]
Message-ID: <3624012.MiIzIq7dko@blindfold> (raw)
In-Reply-To: <20181103035341.16893-1-helen.koike@collabora.com>
Helen,
Am Samstag, 3. November 2018, 04:53:39 CET schrieb Helen Koike:
> As mentioned in the discussion from the previous version of this patch, Android
> and Chrome OS do not use initramfs mostly due to boot time and size liability.
Do you have numbers on that?
I understand that using something like dracut with systemd inside is not what you
want from a boot time point of view.
But having an initramfs embedded into the kernel image which contains only a single
static linked binary can be *very* small and fast.
If you invest a little more time, you don't even need a libc, just fire up some
syscalls to setup your dm. I use this technique regularly on deeply embedded systems
to setup non-trivial UBIFS/crypto stuff.
Want I'm trying to say, before adding ad-hoc a feature to the kernel, we should be
very sure that there is no other way to solve this in a sane manner.
We have initramfs support for reasons.
Thanks,
//richard
next prev parent reply other threads:[~2018-11-03 9:10 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-03 3:53 [PATCH v10 0/2] dm: boot a mapped device without an initramfs Helen Koike
2018-11-03 3:53 ` [linux-lvm] " Helen Koike
2018-11-03 3:53 ` [PATCH v10 1/2] dm ioctl: add a device mapper ioctl function Helen Koike
2018-11-03 3:53 ` [linux-lvm] " Helen Koike
2018-11-03 3:53 ` [PATCH v10 2/2] init: add support to directly boot to a mapped device Helen Koike
2018-11-03 3:53 ` [linux-lvm] " Helen Koike
2018-11-03 9:10 ` Richard Weinberger [this message]
2018-11-03 9:10 ` [linux-lvm] [PATCH v10 0/2] dm: boot a mapped device without an initramfs Richard Weinberger
2018-11-06 14:24 ` Will Drewry
2018-11-06 14:24 ` [linux-lvm] " Will Drewry
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=3624012.MiIzIq7dko@blindfold \
--to=richard@nod.at \
--cc=agk@redhat.com \
--cc=dm-devel@redhat.com \
--cc=enric.balletbo@collabora.com \
--cc=helen.koike@collabora.com \
--cc=keescook@chromium.org \
--cc=kernel@collabora.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-lvm@redhat.com \
--cc=snitzer@redhat.com \
--cc=wad@chromium.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.