From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stephen Leake Newsgroups: gmane.emacs.devel Subject: Re: emacs-dynamic-module in Emacs Git? Date: Wed, 03 Dec 2014 04:04:40 -0600 Message-ID: <85d281jbgn.fsf@stephe-leake.org> References: <87wq6tu5m5.fsf@kima.orebokech.com> <85h9xwhpy9.fsf@stephe-leake.org> <87k32sh50f.fsf@lifelogs.com> <85tx1rg64e.fsf_-_@stephe-leake.org> <87siha7r3b.fsf@lifelogs.com> <87lhmz4mtj.fsf@lifelogs.com> <87sih575rc.fsf@lifelogs.com> <8361dyaqf1.fsf@gnu.org> <83zjb771px.fsf@gnu.org> <851tojm0z6.fsf@stephe-leake.org> <838uiq7m8b.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1417601180 30963 80.91.229.3 (3 Dec 2014 10:06:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 3 Dec 2014 10:06:20 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Dec 03 11:06:15 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Xw6p4-0001Ti-Kn for ged-emacs-devel@m.gmane.org; Wed, 03 Dec 2014 11:06:14 +0100 Original-Received: from localhost ([::1]:40648 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xw6p4-0004ZA-2v for ged-emacs-devel@m.gmane.org; Wed, 03 Dec 2014 05:06:14 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54986) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xw6ng-0003aL-87 for emacs-devel@gnu.org; Wed, 03 Dec 2014 05:04:53 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xw6na-0005Uc-TW for emacs-devel@gnu.org; Wed, 03 Dec 2014 05:04:48 -0500 Original-Received: from dnvrco-outbound-snat.email.rr.com ([107.14.73.231]:5363 helo=dnvrco-oedge-vip.email.rr.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xw6na-0005UW-N0 for emacs-devel@gnu.org; Wed, 03 Dec 2014 05:04:42 -0500 Original-Received: from [70.94.38.149] ([70.94.38.149:51191] helo=TAKVER) by dnvrco-oedge02 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id 76/E7-16151-930EE745; Wed, 03 Dec 2014 10:04:41 +0000 In-Reply-To: <838uiq7m8b.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 02 Dec 2014 05:40:36 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.94 (windows-nt) X-RR-Connecting-IP: 107.14.64.130:25 X-Authority-Analysis: v=2.1 cv=bePlUY/B c=1 sm=1 tr=0 a=AppmJ/7ZOOFWL/q6u6u93g==:117 a=AppmJ/7ZOOFWL/q6u6u93g==:17 a=ayC55rCoAAAA:8 a=fNEgcOh0sVsA:10 a=9i_RQKNPAAAA:8 a=mDV3o1hIAAAA:8 a=Ud_lSONgn5diRnv9VdkA:9 a=nyCQhBA_uazmBYn9:21 a=44US6QcnpwKEpdu9:21 X-Cloudmark-Score: 0 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 107.14.73.231 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:178722 Archived-At: Eli Zaretskii writes: >> From: Stephen Leake >> Date: Mon, 01 Dec 2014 16:58:21 -0600 >> >> Eli Zaretskii 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