From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id EF5A87FCCB for ; Mon, 27 Apr 2015 11:54:36 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of info@gerd-stolpmann.de) identity=pra; client-ip=212.227.126.130; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="info@gerd-stolpmann.de"; x-sender="info@gerd-stolpmann.de"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of info@gerd-stolpmann.de) identity=mailfrom; client-ip=212.227.126.130; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="info@gerd-stolpmann.de"; x-sender="info@gerd-stolpmann.de"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mout.kundenserver.de) identity=helo; client-ip=212.227.126.130; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="info@gerd-stolpmann.de"; x-sender="postmaster@mout.kundenserver.de"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CXAQCVBj5VlIJ+49RcgyE+XIMaxHIMhUQ+AoEuPBABAQEBAQEBEQEBAQEHCwsJHzCEIQEBBCMyJBALGCoCAlcGEwkShWCCNAmxOBMhbw2SJQEBAQEBAQEDAQEBAQEBHIs4gmuBdCYHgi0MLxKBMwWGQotfAYM0jW4DjiiCCIIRbQEEgj8BAQE X-IPAS-Result: A0CXAQCVBj5VlIJ+49RcgyE+XIMaxHIMhUQ+AoEuPBABAQEBAQEBEQEBAQEHCwsJHzCEIQEBBCMyJBALGCoCAlcGEwkShWCCNAmxOBMhbw2SJQEBAQEBAQEDAQEBAQEBHIs4gmuBdCYHgi0MLxKBMwWGQotfAYM0jW4DjiiCCIIRbQEEgj8BAQE X-IronPort-AV: E=Sophos;i="5.11,656,1422918000"; d="asc'?scan'208";a="137733725" Received: from mout.kundenserver.de ([212.227.126.130]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 27 Apr 2015 11:54:36 +0200 Received: from office1.lan.sumadev.de ([178.4.18.152]) by mrelayeu.kundenserver.de (mreue005) with ESMTPSA (Nemesis) id 0M94Cf-1Yat4q0htl-00CQdP; Mon, 27 Apr 2015 11:52:05 +0200 Received: from [192.168.65.22] (office6.fritz.box [192.168.65.22]) by office1.lan.sumadev.de (Postfix) with ESMTPSA id 85CBEDC05D; Mon, 27 Apr 2015 11:52:04 +0200 (CEST) Message-ID: <1430128317.3427.70.camel@zotac> From: Gerd Stolpmann To: =?ISO-8859-1?Q?Fran=E7ois?= Bobot Cc: =?ISO-8859-1?Q?St=E9phane?= Glondu , OCaml Mailing List Date: Mon, 27 Apr 2015 11:51:57 +0200 In-Reply-To: <552D0BFE.7000904@cea.fr> References: <54F5B3F7.3030705@cea.fr> <1425394551.4056.1.camel@thinkpad.lan.sumadev.de> <54F6D731.3090004@cea.fr> <1428953391.22412.40.camel@e130.lan.sumadev.de> <552CD705.9000508@cea.fr> <552CE242.9050307@glondu.net> <552D0BFE.7000904@cea.fr> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-VZeVrxOuJ9C9GBJ4krBa" X-Mailer: Evolution 3.10.4-0ubuntu2 Mime-Version: 1.0 X-Provags-ID: V03:K0:yOm28wu2UQYHIcjDrx4GoXRcHBTwVvcdU4NeRGWvxNcaK8XgK4R 4bXyLT73lOTJpDMb7V22wT4+dP/X+jhB8jQohYoLpR2P3R9zNx/xModc8JrUNfUPrIJM1BC x4KJb06dk3facYOvTVfXbQH03aYWe8ryDw4wDq/EEbTN8EWL6whuhj/0H8ntpsRkQbiZEDI 7ctMHRb2DUp4KGdAJ03KA== X-UI-Out-Filterresults: notjunk:1; Subject: Re: [Caml-list] Dependencies between plugins --=-VZeVrxOuJ9C9GBJ4krBa Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Fran=C3=A7ois, I was thinking again about this issue. Introducing a third category "shared" in addition to byte and native seems to be a bit odd. Actually, what we really want to have is a second dimension plugin/executable in addition to the already existing byte/native dimension, so that we can have: - byte + executable (cmo) - native + executable (cmx) - byte + plugin (cmo, too) - native + plugin (cmxs) That way we can have a separate cmo for byte+plugin, which may be useful here and there. Also, byte and native are again symmetric. A typical META file would now specify archive(byte,executable) =3D "..." archive(native,executable) =3D "..." if it doesn't support plugins, and specify archive(byte,executable) =3D "..." archive(native,executable) =3D "..." archive(byte,plugin) =3D "..." archive(native,plugin) =3D "..." if it does so. (NB. "executable" because these are the objects for creating executables.) The only remaining question is how to handle existing META files that don't make this distinction. We don't have a version number in META files, so we have to watch out for another criterion. I am thinking about understanding archive(native) =3D "..." as archive(native,executable) =3D "..." if there is no other reference to the executable predicate. This would be a special fixup after parsing META. After a transition phase (say, two years from now on) we would consider archive(native) as an error. The upcoming META lint will report this issue. This way, the existing META files can still be used for some time, including those specifying plugins. There is no hurry in changing this detail. However, you are absolutely right that the current use of "plugin" breaks the way the predicates are defined, and in the long term this is worth fixing. Gerd Am Dienstag, den 14.04.2015, 14:45 +0200 schrieb Fran=C3=A7ois Bobot: > On 14/04/2015 11:47, St=C3=A9phane Glondu wrote: > > Le 14/04/2015 10:59, Fran=C3=A7ois Bobot a =C3=A9crit : > >>>> Are there any movement in this direction, or this patches will die? > >>> > >>> Don't think so. Slowness on my side. > >> > >> On my side, I haven't yet written the documentation. My main impediment > >> is to choose which predicates to use for the cmxs in the META file: > >> 1) to keep archive(plugin,native) because it is the defacto standard > >> 2) to move to something that is semantically right: > >> archive(native_plugin) or archive(shared). > > > > Sorry, I didn't follow the whole discussion but... this looks like > > hardcoding a special treatment of plugins for the native case, > > forgetting the bytecode case. Would you introduce byte_plugin (or a > > bytecode counterpart to "shared" which looks bad to me) as well? >=20 > The fact is that native and bytecode are not symmetric: > | byte | native > static link | cmo | cmx > dynamic link | cmo | cmxs >=20 > So for bytecode we can still use `archive(byte)`. If someone wants its li= brary to be loaded=20 > differently in static linking and dynamic linking e can use `archive(byte= ,plugin)`. >=20 > You are right that I should give a full proposal (I'm going to go with `s= hared` instead of=20 > `native_plugin` because it is short and correspond to the ocamlopt option= ): >=20 > 1. In META file: > 1.1 use `archive(byte)` and `archive(native)` for the files to statica= lly link > 1.2 use `archive(byte,plugin)` for the files to dynamically link in by= tecode if they are=20 > different from the static one > 1.3 use `archive(shared)` for the files that are dynamically linked in= native code >=20 > 2. During dynamic loading: > 2.1. in bytecode: look for variable `archive` with predicates `byte`,`= plugin` and the other=20 > predicates used during compilation (`mt`, `mt_posix`, `mt_vm`, `gprof`, .= ..) > 2.2 in native: look for variable `archive` with predicates `shared`, = `plugin` and the other=20 > predicates used during static linking except `native` >=20 >=20 > My goal is just that when you ask in native code "Does this library defin= e files for dynamic=20 > linking" the answer is not "yes, it defines these cmx". There are other s= olutions (like asking that=20 > file to statically link are define with `archive(native,-plugin)`) but th= ey seem to be less=20 > conservative. >=20 > > Even > > code using Dynlink should be as generic (w.r.t. native/bytecode) as > > possible... >=20 >=20 > The examples of tools that use dependencies between plugins gathered at t= he start of the discussion=20 > are already not generic (w.r.t. native/bytecode) : >=20 > The following code makes a differences between bytecode and native code: > https://github.com/ocsigen/ocsigenserver/blob/master/src/baselib/ocsigen_= loader.ml#L165 > https://github.com/zoggy/stog/blob/e83c363c83465a7bfd1595816b3d9bc8331af5= 60/stog_dyn.ml#L119-L146 >=20 > This one works only for native code, it seems: > https://github.com/hammerlab/ketrew/blob/master/src/lib/pure/ketrew_plugi= n.ml#L52 >=20 > The proposed modification is to replace (for example in ocsigen): >=20 > ```ocaml > (if Ocsigen_config.is_native then "native" else "byte") > ``` >=20 > by >=20 > ```ocaml > (if Ocsigen_config.is_native then "shared" else "byte") > ``` >=20 > --=20 > Fran=C3=A7ois >=20 >=20 --=20 ------------------------------------------------------------ Gerd Stolpmann, Darmstadt, Germany gerd@gerd-stolpmann.de My OCaml site: http://www.camlcity.org Contact details: http://www.camlcity.org/contact.html Company homepage: http://www.gerd-stolpmann.de ------------------------------------------------------------ --=-VZeVrxOuJ9C9GBJ4krBa Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAABAgAGBQJVPga9AAoJEAaM4b9ZLB5TlMMH/j81R4BhcCEHCdJ2/jJN4MJz lCNualuvgKt0xzrVHxEJ/tdacrSRYuthRaw71e1aM8MHP1GMGZaEB85msT2h0tz/ 6iTthXAFyT4IF9XH86FJl1zO+UYrJGaBdMGk/VlQ/2b5VYBEyAQqmhvrv0venhdp LhyVZjtwhz8XC5s526BtW/6jeC9Or67L+d3MWMrutmH/+b68t2oELgupsRwz6osu ULMvIOdk0RrQxfaOhv2peg4Xi5OHBw/vxM365KIrEpuo4tRu3BC52cboSnLPD1QP VTZcuDcH4pRV5uzvfDHHbyo7WNd5S/TGVbjgwJ2cPQNytmsEWnbwrse+wSLVat4= =yDH0 -----END PGP SIGNATURE----- --=-VZeVrxOuJ9C9GBJ4krBa--