linux-kernel - Re: [PATCH v4 2/4] block: partitions: populate fwnode

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Zn6vjmNf4QjBkqh6@infradead.org>
Date: Fri, 28 Jun 2024 05:41:50 -0700
From: Christoph Hellwig <hch@...radead.org>
To: Daniel Golle <daniel@...rotopia.org>
Cc: Christoph Hellwig <hch@...radead.org>, Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Ulf Hansson <ulf.hansson@...aro.org>, Jens Axboe <axboe@...nel.dk>,
	Hauke Mehrtens <hauke@...ke-m.de>, Felix Fietkau <nbd@....name>,
	Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
	Dave Chinner <dchinner@...hat.com>, Jan Kara <jack@...e.cz>,
	Christian Brauner <brauner@...nel.org>,
	Thomas Weißschuh <linux@...ssschuh.net>,
	Al Viro <viro@...iv.linux.org.uk>,
	Li Lingfeng <lilingfeng3@...wei.com>,
	Christian Heusel <christian@...sel.eu>,
	Min Li <min15.li@...sung.com>, Avri Altman <avri.altman@....com>,
	Adrian Hunter <adrian.hunter@...el.com>,
	Hannes Reinecke <hare@...e.de>,
	Mikko Rapeli <mikko.rapeli@...aro.org>, Yeqi Fu <asuk4.q@...il.com>,
	Victor Shih <victor.shih@...esyslogic.com.tw>,
	Christophe JAILLET <christophe.jaillet@...adoo.fr>,
	Li Zhijian <lizhijian@...itsu.com>,
	"Ricardo B. Marliere" <ricardo@...liere.net>,
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-mmc@...r.kernel.org, linux-block@...r.kernel.org
Subject: Re: [PATCH v4 2/4] block: partitions: populate fwnode

On Fri, Jun 28, 2024 at 01:16:13PM +0100, Daniel Golle wrote:
> > Overly long lines, which is really annyoing for block comments.
> 
> Should I use 80 chars as limit everywhere?

In my opinion that makes things easier.  The coding style allows to
exceed it for individual lines where it improves readability, which
is a bit of an odd case.

> > Can we please not use the crazy part_meta stuff for anything new?
> > We should never have merge it, and right now it is at least isolated
> > to the boot time root dev_t partsing, and I'd really prefer to keep it
> > in that corner.
> > 
> 
> At least up to my understanding there isn't any other to know a
> partitions UUID or volume name.
> 
> If there is another way to access this information I'd happily make
> use of it, but I couldn't find any.

That is true, but except for the early dev_t parsing we actually never
use these partition uuids in the kernel at all.  Also in all the
normal file system references either use the file system uuid,
or the device provided one for devices that support them.  Most of
that is handled entirely in userspace, though - the kernel largely
operates just on the dev_t.