From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.devel Subject: Re: DSO-style FFI Date: Wed, 09 Oct 2013 19:21:09 -0400 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <874n8qt4ii.fsf@flea.lifelogs.com> References: <877gdqrc9u.fsf@flea.lifelogs.com> <87mwmmp05f.fsf@flea.lifelogs.com> <87fvsdpato.fsf@flea.lifelogs.com> <8738oc20xk.fsf@flea.lifelogs.com> <87d2ngzlyl.fsf_-_@flea.lifelogs.com> <87siwcxda7.fsf@flea.lifelogs.com> <87zjqjfz36.fsf@fleche.redhat.com> <87wqlnv9bn.fsf@flea.lifelogs.com> <877gdnfq84.fsf@fleche.redhat.com> Reply-To: emacs-devel@gnu.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1381360883 21778 80.91.229.3 (9 Oct 2013 23:21:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 9 Oct 2013 23:21:23 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Oct 10 01:21:27 2013 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 1VU34G-0000xb-EX for ged-emacs-devel@m.gmane.org; Thu, 10 Oct 2013 01:21:24 +0200 Original-Received: from localhost ([::1]:44257 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VU34F-0007zi-N8 for ged-emacs-devel@m.gmane.org; Wed, 09 Oct 2013 19:21:23 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55838) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VU345-0007zV-Tl for emacs-devel@gnu.org; Wed, 09 Oct 2013 19:21:20 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VU340-0001EO-8P for emacs-devel@gnu.org; Wed, 09 Oct 2013 19:21:13 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:59484) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VU340-0001DZ-1Q for emacs-devel@gnu.org; Wed, 09 Oct 2013 19:21:08 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1VU33y-0000mn-R7 for emacs-devel@gnu.org; Thu, 10 Oct 2013 01:21:06 +0200 Original-Received: from c-98-229-61-72.hsd1.ma.comcast.net ([98.229.61.72]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 10 Oct 2013 01:21:06 +0200 Original-Received: from tzz by c-98-229-61-72.hsd1.ma.comcast.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 10 Oct 2013 01:21:06 +0200 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Original-Lines: 84 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: c-98-229-61-72.hsd1.ma.comcast.net X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6; d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" Mail-Copies-To: never User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3.50 (gnu/linux) Cancel-Lock: sha1:OQ0aCxWDD0NpFD8l4g1Cj9dL9MU= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 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:164050 Archived-At: On Tue, 08 Oct 2013 14:43:39 -0600 Tom Tromey wrote: Ted> The foreign function has to take Emacs Lisp_Objects (maybe just strings Ted> and numbers) and package its return data in a Lisp_Object. So how do we Ted> handle that glue with libffi or anything else without promising some Ted> minimal internal Emacs ABI? Tom> The idea is to have the FFI code be part of Emacs. So when Emacs Tom> changes, it does too. What doesn't change is the API presented to Tom> elisp. Tom> This is how FFI works in other languages -- Common Lisp, Python, Tom> probably Guile (I didn't check), Java (it's part of reflection there), Tom> etc. It would really help if we discussed a small example, and forgive my ignorance here. Say I have a transforming function: int gnutls_xform(char* datain, char* dataout); I want to use a Lisp_Object, a string, for `datain'; and get back another Lisp_Object, again a string, in `dataout'. So, something like this would be done on a given function_pointer to `gnutls_xform', with some given Lisp_Object `input_data': ffi_cif cif; ffi_type *args[2]; void *values[2]; char *in = SDATA (input_data); char *out = xzmalloc(100); int rc; args[0] = &ffi_type_pointer; values[0] = ∈ args[1] = &ffi_type_pointer; values[1] = &out; /* Initialize the cif */ if (ffi_prep_cif(&cif, FFI_DEFAULT_ABI, 1, &ffi_type_uint, args) == FFI_OK) { ffi_call(&cif, function_pointer, &rc, values); /* rc now holds the result of the call */ } Lisp_Object ret = Qnil; // if rc shows success... if (rc != ERROR) { ret = make_string (out); } xfree(out); This would be more generic of course, but keeping it simple for now really helps. As far as the dynamic function loading to give us function_pointer, I am guessing it's done with libltdl, by calling module = lt_dlopen("emacs_gnutls_module"); and then lt_dlsym(module, "gnutls_xform"); as shown in http://www.gnu.org/software/libtool/manual/html_node/Libltdl-interface.html Is that more or less where we should be going? Is this today's state of the art? Based on the other languages you listed, it seems so. My immediate concerns are security (these modules can do almost anything); concurrency between modules and Emacs; and between modules loaded by concurrent Emacs threads in a hypothetical future where we have such threads. But in terms of practical integration they seem workable. Thanks for your patience Ted