Built-in plugins?

[Aleksander Morgado]

Hey Dan and Matthew,

>>
>> But if you wanted to, you
>> could pass --enable-plugins=X,Y,Z or something and end up with a
>> smaller binary.
>
> I like that. It put's the optimization in the hands of the builder which
> seems more than fair to have integrator's figure out what goes in
> or out & dependency chains. It also will sit better in build systems
> like Yocto IMO since you are only building installing what is
> needed during make.
>
> On Mon, Nov 18, 2019 at 9:31 AM Aleksander Morgado <aleksander at aleksander.es> wrote:
>>
>> Hey Dan!
>>
>> > > > > Is there any benefit in keeping per-vendor plugins installed as
>> > > > > separate .so files and loaded during runtime?
>> > > >
>> > > > I think it'd be a shame to lose this architecture. On embedded
>> > > > systems saving resources is always desirable and I remove
>> > > > all vendor plugins that do not apply to an embedded hardware
>> > > > footprint. The most common complaints that get raised to me to
>> > > > avoid use MM for embedded systems is footprint. I'd hate to give
>> > > > reasons to communities like OpenWRT to make a point out of that.
>> > > >
>> > > > > Thinking of installed size, I believe we may end up duplicating a
>> > > > > lot
>> > > > > of code when plugins share common code, as the utils libraries
>> > > > > are not
>> > > > > installed, they get incorporated in the plugins themselves. This
>> > > > > also
>> > > > > makes some unexpected runtime errors if a plugin tries to
>> > > > > register a
>> > > > > type that some other plugin has already registered (just had this
>> > > > > one
>> > > > > today with the new Foxconn plugin in git master, which shares
>> > > > > code
>> > > > > with the Dell plugin).
>> > > >
>> > > > Respectfully this just seems like poor plugin design. Why should it
>> > > > be okay to create dependencies between plugins. Shouldn't shared
>> > > > logic be in a share location if it really is common code? And if
>> > > > it's
>> > > > shared but not applicable to all then maybe it should just be
>> > > > copied.
>> > > >
>> > >
>> > > You're right, that was indeed poor plugin design. Up until now we
>> > > were
>> > > "copying" as you said, but that would break the GType system when
>> > > multiple plugins tried to create objects of the same type. I've tried
>> > > to fix the plugin design my creating a new set of installed modules
>> > > that provide the shared utils to the plugins, please see:
>> > >
>> > > https://gitlab.freedesktop.org/mobile-broadband/ModemManager/merge_requests/209
>> > >
>> > > Due to the copy no longer being done, the overall size of all .so
>> > > files installed in /usr/lib/ModemManager went from 7MB to 5.5MB in my
>> > > machine, even with the new shared modules installed. Comments
>> > > welcome!
>> > >
>> > > > > I would bet there isn't any as we truly haven't kept a stable
>> > > > > plugin
>> > > > > API like never ever.
>> > > >
>> > > > Ya but industrial users, for the worst, often tend to get a certain
>> > > > version and stick with it. The API changing in that case doesn't
>> > > > matter.
>> > > > With 5G on the door step there may be some new vendors that want to
>> > > > have a proprietary plugin while they think their new API is god's
>> > > > gift
>> > > > to humanity, cough cough hint hint. I love the GPL but losing the
>> > > > plugin
>> > > > framework feels bad as someone who's had to deal with the bidding's
>> > > > of mega-corp's and legal team's choices bases on lawyer bro's
>> > > > understanding of software.
>> > > >
>> > >
>> > > As long as they don't update the ModemManager version, that would
>> > > work. But note that not even stable MM updates (e.g. 1.10.0->1.10.2)
>> > > the plugin API is maintained. Of course, if they are the ones
>> > > building
>> > > MM as well, that's a different story, but then I wouldn't call that
>> > > an
>> > > external plugin, it really would be a totally different MM in my
>> > > opinion. The fact that it's developed as a plugin doesn't make it a
>> > > "proper plugin" if you know what I mean.
>> >
>> > Another option to address Matthew's concern would be compile-time
>> > selectable plugins. We would still keep the general plugin architecture
>> > (eg the concept of separate/encapsulated code modules for each type of
>> > hardware) since I think that's a good thing to do from a software
>> > engineering and architecture point of view. But if you wanted to, you
>> > could pass --enable-plugins=X,Y,Z or something and end up with a
>> > smaller binary.
>> >
>>
>> That's definitely something we could have, yes. Actually, I recall a
>> patch doing that from Gimp's mitch, but that got lost in some old
>> Lanedo git repo.
>>
>> As long as the plugins hierarchy is enforced by the build system (e.g.
>> see this commit for the dependencies between them:
>> https://gitlab.freedesktop.org/mobile-broadband/ModemManager/merge_requests/209/diffs?commit_id=93123d7665da1bd6b6765dfe92a71f2ff125d41f)
>> we should be able to have selectable plugins during configure, which
>> is definitely a much saner thing to do than cherry-picking which
>> plugins are installed during the install phase.
>>

I've updated the Merge Request with an additional commit that allows
selecting the list of plugins to build and install during configure.
By default all plugins are enabled (--enable-all-plugins is implicit),
but this can be changed with --disable-all-plugins to by default
disable all. Please check:
https://gitlab.freedesktop.org/mobile-broadband/ModemManager/merge_requests/209

E.g. to just select a couple of plugins you can do:
$ ./configure --disable-all-plugins --enable-plugin-generic --enable-plugin-zte

Or to instead deselect just some of them:
$ ./configure --disable-plugin-dell --disable-plugin-option-hso

The build setup takes care of only building and installing the "shared
util" libraries that are appropriate depending on which plugins are
enabled.

-- 
Aleksander
https://aleksander.es