All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Weinberger <richard@nod.at>
To: Daniel Golle <daniel@makrotopia.org>
Cc: chengzhihao1 <chengzhihao1@huawei.com>,
	 Miquel Raynal <miquel.raynal@bootlin.com>,
	 Vignesh Raghavendra <vigneshr@ti.com>, robh <robh@kernel.org>,
	 Krzysztof Kozlowski <krzk+dt@kernel.org>,
	 Conor Dooley <conor+dt@kernel.org>,
	John Crispin <john@phrozen.org>,
	 linux-mtd <linux-mtd@lists.infradead.org>,
	 devicetree <devicetree@vger.kernel.org>,
	 linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH RFC 2/2] mtd: ubi: add support for protecting critical volumes
Date: Mon, 30 Sep 2024 21:54:07 +0200 (CEST)	[thread overview]
Message-ID: <1249604143.124110.1727726047386.JavaMail.zimbra@nod.at> (raw)
In-Reply-To: <Zvr-hOM2DfveaqeC@makrotopia.org>

----- Ursprüngliche Mail -----
> Von: "Daniel Golle" <daniel@makrotopia.org>
>> like a ubirmvol ... --i-know-what-im-doing.
> 
> True, enforcement doesn't need to happen in kernel (though I think it's
> nicer, but really just a matter of taste, I guess). ubi-tools would still
> need to be able to recognize critical volumes somehow, and that could be
> done by checking if the 'volume-is-critical' property is present in
> /sys/class/ubi/ubi*_*/of_node/

Exactly.
I also don't mind adding a in-memory 'volume-is-critical' property to
UBI directly. I'm just a little hesitated to change the UAPI or the on-disk
data structures for this features.
 
> If you prefer going down that road instead I will work on patches for
> git.infradead.org/mtd-utils.git instead.

Yes. When done in userspace, it's also much easier to offer the --i-know-what-im-doing
flag to still remove a critical volume.
No need to touch UAPI.

Zhihao Cheng, what do you think about this approach?

Thanks,
//richard

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

WARNING: multiple messages have this Message-ID (diff)
From: Richard Weinberger <richard@nod.at>
To: Daniel Golle <daniel@makrotopia.org>
Cc: chengzhihao1 <chengzhihao1@huawei.com>,
	 Miquel Raynal <miquel.raynal@bootlin.com>,
	 Vignesh Raghavendra <vigneshr@ti.com>, robh <robh@kernel.org>,
	 Krzysztof Kozlowski <krzk+dt@kernel.org>,
	 Conor Dooley <conor+dt@kernel.org>,
	John Crispin <john@phrozen.org>,
	 linux-mtd <linux-mtd@lists.infradead.org>,
	 devicetree <devicetree@vger.kernel.org>,
	 linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH RFC 2/2] mtd: ubi: add support for protecting critical volumes
Date: Mon, 30 Sep 2024 21:54:07 +0200 (CEST)	[thread overview]
Message-ID: <1249604143.124110.1727726047386.JavaMail.zimbra@nod.at> (raw)
In-Reply-To: <Zvr-hOM2DfveaqeC@makrotopia.org>

----- Ursprüngliche Mail -----
> Von: "Daniel Golle" <daniel@makrotopia.org>
>> like a ubirmvol ... --i-know-what-im-doing.
> 
> True, enforcement doesn't need to happen in kernel (though I think it's
> nicer, but really just a matter of taste, I guess). ubi-tools would still
> need to be able to recognize critical volumes somehow, and that could be
> done by checking if the 'volume-is-critical' property is present in
> /sys/class/ubi/ubi*_*/of_node/

Exactly.
I also don't mind adding a in-memory 'volume-is-critical' property to
UBI directly. I'm just a little hesitated to change the UAPI or the on-disk
data structures for this features.
 
> If you prefer going down that road instead I will work on patches for
> git.infradead.org/mtd-utils.git instead.

Yes. When done in userspace, it's also much easier to offer the --i-know-what-im-doing
flag to still remove a critical volume.
No need to touch UAPI.

Zhihao Cheng, what do you think about this approach?

Thanks,
//richard

  reply	other threads:[~2024-09-30 19:54 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-28 12:47 [PATCH RFC 1/2] dt-bindings: mtd: ubi-volume: add 'volume-is-critical' property Daniel Golle
2024-09-28 12:47 ` Daniel Golle
2024-09-28 12:48 ` [PATCH RFC 2/2] mtd: ubi: add support for protecting critical volumes Daniel Golle
2024-09-28 12:48   ` Daniel Golle
2024-09-29 12:26   ` Richard Weinberger
2024-09-29 12:26     ` Richard Weinberger
2024-09-30  1:56     ` Zhihao Cheng
2024-09-30  1:56       ` Zhihao Cheng
2024-09-30 18:43       ` Richard Weinberger
2024-09-30 18:43         ` Richard Weinberger
2024-09-30 19:39         ` Daniel Golle
2024-09-30 19:39           ` Daniel Golle
2024-09-30 19:54           ` Richard Weinberger [this message]
2024-09-30 19:54             ` Richard Weinberger
2024-10-08  2:55             ` Zhihao Cheng
2024-10-08  2:55               ` Zhihao Cheng
2024-09-28 13:02 ` [PATCH RFC 1/2] dt-bindings: mtd: ubi-volume: add 'volume-is-critical' property Krzysztof Kozlowski
2024-09-28 13:02   ` Krzysztof Kozlowski
2024-09-28 13:09   ` Daniel Golle
2024-09-28 13:09     ` Daniel Golle
2024-09-28 13:45     ` Krzysztof Kozlowski
2024-09-28 13:45       ` Krzysztof Kozlowski
2024-09-28 14:38       ` Daniel Golle
2024-09-28 14:38         ` Daniel Golle
2024-09-29  4:03         ` Zhihao Cheng
2024-09-29  4:03           ` Zhihao Cheng
2024-09-29 10:52           ` Daniel Golle
2024-09-29 10:52             ` Daniel Golle
2024-09-29 11:23             ` Zhihao Cheng
2024-09-29 11:23               ` Zhihao Cheng
2024-09-29 12:16               ` Daniel Golle
2024-09-29 12:16                 ` Daniel Golle

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=1249604143.124110.1727726047386.JavaMail.zimbra@nod.at \
    --to=richard@nod.at \
    --cc=chengzhihao1@huawei.com \
    --cc=conor+dt@kernel.org \
    --cc=daniel@makrotopia.org \
    --cc=devicetree@vger.kernel.org \
    --cc=john@phrozen.org \
    --cc=krzk+dt@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=miquel.raynal@bootlin.com \
    --cc=robh@kernel.org \
    --cc=vigneshr@ti.com \
    /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.