Re: emacs-dynamic-module in Emacs Git?

[Stephen Leake <stephen_leake@stephe-leake.org>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Stephen Leake <stephen_leake@stephe-leake.org>
>> Date: Mon, 01 Dec 2014 16:58:21 -0600
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >
>> >> >   . It seems to me that the modules call functions implemented by
>> >> >     Emacs, like make_number and Fmember, on the assumption that
>> >> >     calling any Emacs function will "just work".  This is false for
>> >> 
>> >> I had to add a linker flag to expose every symbol of Emacs. See the
>> >> relevant commit:
>> >> 
>> >> http://git.savannah.gnu.org/cgit/emacs.git/commit/configure.ac?h=dynamic-modules&id=5c710fba15e0a3a2ae5d831e5cdb555332238752
>> >
>> > I don't think this is correct: we don't really want to export all the
>> > symbols.
>> 
>> Why not?
>
> Security: you don't want to expose all of the Emacs bowels to any
> external program out there.

There are many other aspects to security; I doubt this particular
strategy will really help.

There are better ways to prevent bad code getting into Emacs; code
reviewed signed modules is probably the best way. That's essentially how
we currently prevent bad code in Emacs core.

Hiding a function that a module turns out to need just inhibits
functionality; it does not gain security.

I'm advocating allowing any code that could be in Emacs core to instead
by in a dynamic module, to allow separate development subject to the
same restrictions as Emacs core code - FSF copyright, code review.

Obviously, the ability to load dynamic modules allows users to choose
other modules that do not meet those criteria. But that should not
restrict what we can do in a dynamic module. We are _not_ building a
sandbox, but a powerful development environment; people must be allowed
to shoot themselves in the foot.

> Or ask yourself why the latest GCC and Binutils default to not export
> anything, contrary to what they did in older versions.

I would guess that has more to do with namespace control, but I'd have
to read the rationale to be sure.

Since we are talking about code that is intended to be tightly
integrated with Emacs, we _want_ the Emacs namespace to be visible.

>> If we were writing this code to be included in Emacs core, we'd have
>> access to all of the symbols.
>
> You can have access to symbols via specific protocols without
> exporting everything.  And I'm not sure you really do need access to
> everything.

Protocols tend to get in the way. If a pipe interface was viable, I'd
use it. But it's not; I need direct, tight integration in order to be
fast enough.

I am very sure I don't need access to absolutely every symbol in the
Emacs namespace. But it's not worth the time to try to figure out ahead
of time which ones I might need. I can certainly provide a list of what
was used after I've got a first version working.

Stefan's approach makes sense; try to define an API, but assume it will
change/evolve. I'm simply arguing that it will not be worth the effort.
The only way to find out is to try it.

Stefan's point about maintaining code that was intended to be internal
to some core package because some other package happens to use it is
also valid. That's why I use Ada instead of C - it's much easier to
enforce such visibility rules. 

>> _if_ the module author wants to be somewhat isolated from Emacs changes,
>> and/or support more than one Emacs version, then they will want to stick
>> to some stable subset. But I don't think we can define that subset ahead
>> of time, and it will certainly be a different subset for each module.
>> 
>> We don't have a single .el file that defines the "Emacs core elisp API
>> for packages"; I don't think we can define a .h file for modules either.
>
> You are just re-iterating my doubts about usability and wisdom in this
> feature.

I don't understand.

You say it would be ok to add this code to core Emacs; all of the
statements above would apply to that choice as well.

We are talking about a dynamically linked module in a separate source
repository, as compared to a staticly linked one in the core repository.
Why should that choice affect the choice of the namespace that is
visible to the module?

>> > All this is pretty standard practice on Windows and works well, the
>> > only issue for us is to decide which functions to export (unless we
>> > really want to export all of them, in which case the --export-dynamic
>> > linker switch is all that's needed).
>> 
>> Let's make it simple; export all of them.
>
> The other alternative is also simple; see GNU Make for an example.

By "the other alternative" I assume you mean "define an Emacs module
API"; that's _not_ simple. Proof: no one has done it yet, but "export
all of them" has been done. QED.


Note that there are actually two namespaces we are talking about here;
the compile time namespace, determined by .h files, and the link time
namespace, determined by --export-dynamic and/or link libraries.

The future maintenance issue is best addressed via .h files; don't put
functions you don't want to support in future versions in any .h file,
or have a naming convention that clearly indicates which .h files will
be supported.

I don't see any reason to restrict the link time namespace.

-- 
-- Stephe