Ali Bahrami wrote:
> Garrett D'Amore wrote:
>
> I agree with the sentiment that executable stacks should be
> an opt in feature, and not tied to mapfile syntax. If you want
> to change the world, this is the only comprehensive way to do that,
> and my guess is that it won't break many programs. I sent mail to
> some folks in the Solaris group earlier today proposing that, and
> hopefully something good will come of it.
>
> With that, I'd like to suggest that changing the stack protections is
> not this case.
Agreed.
>
> -----
>
> I'd be happy to phase out the V1 syntax, but we really have no
> way of knowing who is using it, or how. I've chosen to be conservative
> on this, and provide a bridge. I spent years as an ISV, and I know that
> they don't appreciate having to revisit working systems, even for good
> reasons. I don't want to give anyone an excuse not to stay with Solaris
> over something as minor as this. The win of the v2 syntax isn't going to
> be big for these folks anyway --- I would not be proposing a new syntax
> if symbol versioning was the sole concern.
>
> There's not much cost to supporting V1, the extra code is not large, and
> there's no maintenance concern. I think we should support it for a few
> years, and then evaluate the situation once we're well past the
> transition.
>
> Another point: Our Linux/GNU friends support our old symbol versioning
> syntax in their linker, and there's value in making it easy for FOSS
> people to write one file that works in both places.
Okay. But does it make sense to at least *mark* the V1 syntax as
"Obsolete", so that folks understand that there is a newer syntax that
they should be moving to?
>
> -----
>
> I just converted > 600 mapfiles in ON to the new syntax, and my feeling
> is that a tool to convert them would be of limited use. The actual syntax
> changes are simple and mechanical, particularly in the 99% that are
> related
> to symbol versioning. At the same time, I gained some big wins by
> rearranging things and applying conditional input directives, and a
> script can't help with that.
Excellent!
>
> The future blog article in the case materials (new_mapfiles.html)
> provides
> lots of conversion examples, and will be easy to find via google.
Good!
>
> As such, I'm not proposing such a tool as part of this case, but
> agree that it might be added downstream.
Fair enough.
Btw, I'm not issuing a +1 on my own behalf yet, because I've not
actually read your case materials. I'll endeavor to do so sometime next
week.
-- Garrett
