On Wed, Jul 26, 2017 at 11:01:48AM -0400, Tom Rini wrote: > On Wed, Jul 26, 2017 at 02:23:15PM +1000, David Gibson wrote: > > 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 would > > > 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. > > Can we go for incremental progress over time instead of replacing what > was finally accepted? Maybe one or two concrete examples that need > improvement upon, and go from there? Thanks! As a general rule, I'd agree with that approach, but not this time. Incremental improvements are great if you have a solid base from which to work, at the moment we don't. What we have is a half-arsed hack that become widely deployed enough that we have to live with it. -- 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
Attachment:
signature.asc
Description: PGP signature
