On Thu, Jul 27, 2017 at 05:25:34PM +1000, David Gibson wrote: > 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. Are you planning to introduce this new design? I thought the whole point of finally accepting the current state of overlay support was so that we could improve it over time, rather than say that we'll have to re-hash everything all over to add the rest of the functionality that was expected. -- Tom
Attachment:
signature.asc
Description: Digital signature
