From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Gibson Subject: Re: [PATCH 1/2] fdt: Allow stacked overlays phandle references Date: Wed, 26 Jul 2017 14:23:15 +1000 Message-ID: <20170726042315.GA8978@umbus.fritz.box> References: <1497451946-15443-1-git-send-email-pantelis.antoniou@konsulko.com> <1497451946-15443-2-git-send-email-pantelis.antoniou@konsulko.com> <20170703090648.GV13989@umbus.fritz.box> <5967CAA6.6010801@gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="XsxFkDPDWfsXVt/M" Return-path: Content-Disposition: inline In-Reply-To: Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Phil Elwell Cc: Frank Rowand , Nishanth Menon , Rob Herring , Devicetree Compiler , Tom Rini , devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Pantelis Antoniou , Tero Kristo , Simon Glass List-Id: devicetree@vger.kernel.org --XsxFkDPDWfsXVt/M Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 13, 2017 at 08:38:10PM +0100, Phil Elwell wrote: > Can we also consider a mechanism for overlay-local symbols, i.e. symbols > that are used purely to create links within an overlay - perhaps using a > particular naming convention? This would make it easier to instantiate an > overlay multiple times without having to uniquify all symbols, and it wou= ld > avoid polluting the global namespace without reason. I'd really prefer not to add yet more features and complexity to the existing shoddily designed overlay mechanism. I'd prefer for people to focus on a better replacement - which includes considering these sorts of use cases and how to handle them. >=20 > Phil >=20 > On 13 Jul 2017 8:32 pm, "Frank Rowand" wrote: >=20 > > On 07/03/17 02:06, David Gibson wrote: > > > On Wed, Jun 14, 2017 at 05:52:25PM +0300, Pantelis Antoniou wrote: > > >> This patch enables an overlay to refer to a previous overlay's > > >> labels by performing a merge of symbol information at application > > >> time. > > > > > > This seems to be doing things the hard way. > > > > > > You're essentially extending the semantics of overlay application to > > > add the symbol merging. You've implemented these extended semantics > > > in libfdt, which is all very well, but that's not the only overlay > > > application implementation. > > > > > > > > > It seems to me a better approach would be to change dtc's -@ > > > implementation, so that in /plugin/ mode instead of making a global > > > __symbols__ node, it puts it into the individual fragments. That way > > > the existing overlay application semantics will update the __symbols__ > > > node. > > > > If the __symbols__ node was inside a fragment, then the existing > > code would add (or update) a __symbols__ node located at the location > > pointed to by the fragment's target path, instead of updating the > > node /__symbols__. > > > > It makes sense to me to have only one global __symbols__ node instead > > of several. > > > > If there is a global __symbols__ node then we have a single name > > space for symbols. > > > > If there are multiple __symbols__ nodes spread throughout the tree, > > then to me that would imply different name spaces spread throughout > > the tree, where namespaces are determined by fragments. This sounds > > confusing to me. Or if the intent is to have a single name space > > then the __symbols__ information would be scattered throughout the > > tree instead of located in a single node. > > > > My current patch (under review), targeted for Linux 4.13-rc1, puts > > an overlay's __symbols__ node properties into the overlay's > > changeset, so they get added when the overlay is loaded and > > removed when the overlay is unloaded. > > > > -Frank > > > > --=20 David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson --XsxFkDPDWfsXVt/M Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEdfRlhq5hpmzETofcbDjKyiDZs5IFAll4GTIACgkQbDjKyiDZ s5L4QBAAqs93iS+RxNNKZ975Zqiuix6MOBELORkAP+A1ZOZllhGCc2GVZU5h48o4 lgBfR0GLj0Byf6jO/9eDd9xkJGnjmP7RVij8QdYhzGoIULTrIVgCkkkXzvdjm2bW h6pUNgtxhHrBO0dUoVtteg0IHKY7TXY/Bed33Aa+IdTFB5iUA2pDRBuC2kQqOxun sJGlrV1cmhHFlnj81nheP3Emp2UHzHVFOHN3bBXUrWwBIg4jaudK2acevWZDUwJL RZ6DjsQXoXJQuwh47Z9TW/OdNmiwTjRAYNQ8jufX2eKg5H5BDfHUt42muRxihof+ MKDHcGtsHB6xkLM1ERxJw0Y2YKi4ugseXZ5jBrvj5hPyeSch0Kq7Pmz2pocJaB6s 7VWqmJHD3yxSHcukiADZo7DGuTXIVI/Y0dfpqhH2GXqrulieAmINMIaJtKh1rwZW rtaqqhXTewmbp0QJXBTdyYolz9KeD1jvqno7zTKoyx0csLSAFGa6+u2d1c4wcx7L +3e5Tytb1Q9i/NJuUj3PfATLTkxEKFR//+uqEBHbyXdVVzUU/yYoD6U5W3xhNlfL /vtqPDH+rBJ07nymaZlN090tRTGuiajSKBfc26IvOrdPyIW6ybkgH3ZouiFlFc8e KLNNUfYxXOX/UNp244PkUY4VD1ryMSfZJ+zxUm9tLLzPXrm2nNE= =IBMH -----END PGP SIGNATURE----- --XsxFkDPDWfsXVt/M-- -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html