From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: emacs-dynamic-module in Emacs Git? Date: Wed, 03 Dec 2014 19:56:26 +0200 Message-ID: <83iohs62id.fsf@gnu.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> <85d281jbgn.fsf@stephe-leake.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Trace: ger.gmane.org 1417629490 5754 80.91.229.3 (3 Dec 2014 17:58:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 3 Dec 2014 17:58:10 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stephen Leake Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Dec 03 18:58:03 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 1XwEBf-0002YU-73 for ged-emacs-devel@m.gmane.org; Wed, 03 Dec 2014 18:58:03 +0100 Original-Received: from localhost ([::1]:42741 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XwEBe-0002LQ-Qd for ged-emacs-devel@m.gmane.org; Wed, 03 Dec 2014 12:58:02 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46362) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XwEBV-0002L5-Jz for emacs-devel@gnu.org; Wed, 03 Dec 2014 12:57:59 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XwEBP-0006oi-9q for emacs-devel@gnu.org; Wed, 03 Dec 2014 12:57:53 -0500 Original-Received: from mtaout25.012.net.il ([80.179.55.181]:50131) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XwEBO-0006oS-Rz for emacs-devel@gnu.org; Wed, 03 Dec 2014 12:57:47 -0500 Original-Received: from conversion-daemon.mtaout25.012.net.il by mtaout25.012.net.il (HyperSendmail v2007.08) id <0NG000700PJV6S00@mtaout25.012.net.il> for emacs-devel@gnu.org; Wed, 03 Dec 2014 19:51:56 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout25.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NG000LNSPMKT8A0@mtaout25.012.net.il>; Wed, 03 Dec 2014 19:51:56 +0200 (IST) In-reply-to: <85d281jbgn.fsf@stephe-leake.org> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.179.55.181 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:178738 Archived-At: > From: Stephen Leake > Date: Wed, 03 Dec 2014 04:04:40 -0600 >=20 > >> > I don't think this is correct: we don't really want to export = all the > >> > symbols. > >>=20 > >> Why not? > > > > Security: you don't want to expose all of the Emacs bowels to any > > external program out there. >=20 > There are many other aspects to security; I doubt this particular > strategy will really help. >=20 > There are better ways to prevent bad code getting into Emacs; code > reviewed signed modules is probably the best way. See David's response, with which I fully agree. I'm sure you had you= r share of vulnerabilities exploited by bugs if not by malicious software, and you know very well the dangers of such over-exposure. > That's essentially how we currently prevent bad code in Emacs core. How can we code-review modules that are not bundled? We have no control on those whatsoever. > I'm advocating allowing any code that could be in Emacs core to ins= tead > by in a dynamic module, to allow separate development subject to th= e > same restrictions as Emacs core code - FSF copyright, code review. > > Obviously, the ability to load dynamic modules allows users to choo= se > 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 all= owed > to shoot themselves in the foot. I'm okay with allowing people to shoot themselves, but I'm not okay with letting them shoot Emacs. What you suggest is a very slippery slope. If we agree to such an unlimited exposure of internals, I'm quite sure that before long we'l= l have modules all over the place depending on those internals, and their authors will apply pressure not to change the internals on whic= h they happen to depend. I don't think we want Emacs development to become hostage to every package out there. No other project I know of, not even libraries (whose proclaimed raison d'=EAtre is to expose APIs) do that, and for very good reasons. I see no reason why Emacs, of all the packages, should do what no other one does. > > Or ask yourself why the latest GCC and Binutils default to not ex= port > > anything, contrary to what they did in older versions. >=20 > I would guess that has more to do with namespace control, but I'd h= ave > to read the rationale to be sure. Yes, that too. Won't there be problems in that department as well, e.g., if some library function replaced by Emacs clashes with its namesake in the module? With toy modules, this is not a problem, but what about those that will use large libraries, where it's not so eas= y to rename a function? Again, very slippery slope. > Since we are talking about code that is intended to be tightly > integrated with Emacs, we _want_ the Emacs namespace to be visible. I'm not sure who is "we" here. I don't think I've heard Stefan, or anyone else expressing such far-reaching desires. > >> 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. >=20 > 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. A software API is much faster than a pipe, so I don't see how this comparison is useful, or even valid. > I am very sure I don't need access to absolutely every symbol in th= e > Emacs namespace. But it's not worth the time to try to figure out a= head > 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. >=20 > 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 eff= ort. > The only way to find out is to try it. Trying is fine, but it's a two-way street: expect the maintainers to resist adding some of the symbols to your list. There will be negotiations, and at least I will object to granting access to everything, which I consider insane in the long run. Every interface and every bit of internals we expose should be scrutinized to determine whether exposing it is a good idea, how necessary that is, what are its chances to change without notice, etc. > >> _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 subs= et ahead > >> of time, and it will certainly be a different subset for each mo= dule. > >>=20 > >> We don't have a single .el file that defines the "Emacs core eli= sp 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. >=20 > I don't understand. >=20 > 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. When code is added to the core, it is automatically updated when the internals change. That's the huge difference you are overlooking. > We are talking about a dynamically linked module in a separate sour= ce > repository, as compared to a staticly linked one in the core reposi= tory. > Why should that choice affect the choice of the namespace that is > visible to the module? I hope by now you understand my answer to that question. > >> Let's make it simple; export all of them. > > > > The other alternative is also simple; see GNU Make for an example= . >=20 > By "the other alternative" I assume you mean "define an Emacs modul= e > API" Not necessarily. It should be enough to make a list of interfaces to which we allow external linkage. > that's _not_ simple. Proof: no one has done it yet, but "export > all of them" has been done. QED. :-) Do take a look at GNU Make, though. It might be useful to put our case in context and in its true proportions. > Note that there are actually two namespaces we are talking about he= re; > the compile time namespace, determined by .h files, and the link ti= me > namespace, determined by --export-dynamic and/or link libraries. >=20 > 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 fi= le, > or have a naming convention that clearly indicates which .h files w= ill > be supported. If we make the effort to create the header file, restricting the linkage only to those interfaces is a trivial job. > I don't see any reason to restrict the link time namespace. It makes no sense whatsoever to allow linkage to interfaces that are not declared in the header file. Do you expect package authors to reverse-engineer or disassemble Emacs in order to find that info?