[squeak-dev] FFI considered harmless (was: Loading FFI is broken)

Chris Muller asqueaker at gmail.com
Wed Nov 20 02:44:39 UTC 2013


> if a
> superior interface is available via FFI the system should use it over and
> above the plugin interface.

For absolute privacy, though, The End To End Argument convinced me it
would be better to use image-level Cryptography than an external
module via FFI.  Too opaque.

OT: Just thinking about this made me wonder whether password-encrypted
images would be nice to have.  The VM can only launch them when the
proper key (or file) is supplied...  A corresponding primitve to save
the image encrypts with a supplied key.  Secure images?


On Tue, Nov 19, 2013 at 6:12 PM, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> On Tue, Nov 19, 2013 at 12:00 PM, Bert Freudenberg <bert at freudenbergs.de>
> wrote:
>>
>> On 19.11.2013, at 12:35, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>>
>> > Hi All,
>> >
>> >     this is an important discussion that is taking a religious tone that
>> > we should strive to avoid.
>>
>> Let's call it philosophical, "religious" is just flame bait.
>>
>> >  There are good arguments for plugins, namely security and
>> > encapsulation.  There are good arguments for an FFI, namely extensibility
>> > and platform compatibility.
>>
>> Agreed.
>>
>> > [... nice explanation snipped ...]
>>
>> > A number of straw men have been raised against the FFI in this
>> > discussion.
>>
>> No-one has been arguing against FFI in general. We agree an FFI is useful,
>> and a more powerful FFI is better. We just (appear to) disagree on how
>> widely it should be used.
>>
>> > Bert asks "Suppose we add a new VM platform, like a VM running on
>> > JavaScript in the browser. Do you really want to re-implement all the C
>> > libraries utilized via FFI? Or rather a handful of primitives in your
>> > language of choice?".  First it is not clear that one *can* implement these
>> > primitives taking either approach.  If the platform, e.g. JavaScript in a
>> > browser, takes the Squeak plugin approach of preventing access to the
>> > platform except through a restricted set of facilities, then certain
>> > functionality will simply be off-limits, whether one has an FFI or not.
>> > Second, reimplementing all the C libraries isn't obligatory.  If the
>> > platform provides an FFI one simply mates to its FFI and accesses the
>> > underlying libraries.  If it doesn't then that functionality is off-limits,
>> > but that doesn't mean the rest of the system doesn't work.
>>
>> That's where we disagree. If basic functions in the system depend on FFI,
>> and FFI is not available, then the system *does not work* at all. E.g.,
>> there are efforts in other Squeak forks to replace fundamental parts of the
>> system (which currently rely on VM primitives) with FFI calls. That's what I
>> am wary of.
>
>
> I see your concern but it doesn't worry me.  I don't see why the system
> can't be constructed so that it discovers what services are available.  It
> already does that in a number of circumstances.  For example, the menu bar
> includes a system report if class SystemReporter is loaded.  So I can
> imagine that the socket layer would look for an FFI-based implementation and
> use it if available, falling back on the plugin interface if absent.
>
> In these days of build and test slaves this kind of layering is
> straight-forward to manage.
>
>
>> One of the fundamental services of a virtual machine is providing a safe
>> and complete environment for the system to function in. Plugins enrich that
>> environment. But FFI pokes holes into that safe environment, reaching out of
>> the virtual world into the "real" world.
>>
>>
>> Indeed sometimes that is exactly what you need, namely to better interact
>> with the specific host system you are running on. I'm simply saying that we
>> need to clearly separate this from the base system, which should be as
>> independent of the actual host platform as possible.
>
>
> Again I see this as a straw-man.  Yes, the system should be able to provide
> something portable and safe, and feature-rich.  But it should also be able
> to provide access to the broader environment if so desired.  Further, if a
> superior interface is available via FFI the system should use it over and
> above the plugin interface.  The JIT does this, but you'd never notice.  If
> sse instructions are available they get used, etc.  The system already
> adapts to the underlying host (file directory separators, etc).  Whether the
> system is independent of the host or heavily dependent on it is a matter of
> perspective.  One perspective is to say that it provides portable
> abstractions of host facilities.  Whether one goes through an FFI or a
> plugin to provide these abstractions makes little difference.  I would agree
> that we keep the FFI separate from /a/ base system, but not form /all/ base
> systems.  I want support for symbolic links and I don't want to depend on a
> plugin that can't, because the facilities are too different across
> platforms, provide a portable abstraction of symbolic links across unix,
> windows and mac.  I want to be able to launch an arbitrary external program
> and not be limited to a small set of supported programs known by a plugin,
> etc, etc.  These are all valid things to have in a base system, but not
> valid things to have in e.g. a web plugin.
>
>>
>>
>> - Bert -
>>
>>
>
>
>
> --
> best,
> Eliot
>
>
>


More information about the Squeak-dev mailing list