[prev in list] [next in list] [prev in thread] [next in thread] 

List:       busybox
Subject:    Re: switch_root: zap the last directory for the mount point of new-root
From:       Kang-Che Sung <explorer09 () gmail ! com>
Date:       2019-07-19 14:28:03
Message-ID: CADDzAfMnG0vS+Sd5_Y9GzG4vFBeLp-ZeBkSBQsq2oJQTZzpMfw () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


On Friday, July 19, 2019, Kang-Che Sung <explorer09@gmail.com> wrote:
>
> There's side benefit for this patch: In case that overmount fails, we can
have
> a rootfs kept intact (instead of almost destroyed).
>

Correction. It's just a side effect, not a "benefit" worth talking about.

Speaking of, since we are now overmounting the root before zapping the
initramfs, I wonder if we can remove one check about whether the new root
is a mount point (this saves code size; mount() would fail with EINVAL in
that case).

[Attachment #5 (text/html)]

<br><br>On Friday, July 19, 2019, Kang-Che Sung &lt;<a \
href="mailto:explorer09@gmail.com">explorer09@gmail.com</a>&gt; \
wrote:<br>&gt;<br>&gt; There&#39;s side benefit for this patch: In case that \
overmount fails, we can have<br>&gt; a rootfs kept intact (instead of almost \
destroyed).<br>&gt;<br><br>Correction. It&#39;s just a side effect, not a \
&quot;benefit&quot; worth talking about.<br><br>Speaking of, since we are now \
overmounting the root before zapping the initramfs, I wonder if we can remove one \
check about whether the new root is a mount point (this saves code size; mount() \
would fail with EINVAL in that case).



_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox


[prev in list] [next in list] [prev in thread] [next in thread]