<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">But if you wanted to, you could pass --enable-plugins=X,Y,Z or something and end up with a smaller binary.</blockquote><div>I like that. It put's the optimization in the hands of the builder which</div><div>seems more than fair to have integrator's figure out what goes in</div><div>or out & dependency chains. It also will sit better in build systems</div><div>like Yocto IMO since you are only building installing what is</div><div>needed during make. </div></div> <div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Nov 18, 2019 at 9:31 AM Aleksander Morgado <<a href="mailto:aleksander@aleksander.es">aleksander@aleksander.es</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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: > > > > <a href="https://gitlab.freedesktop.org/mobile-broadband/ModemManager/merge_requests/209" rel="noreferrer" target="_blank">https://gitlab.freedesktop.org/mobile-broadband/ModemManager/merge_requests/209</a> > > > > 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: <a href="https://gitlab.freedesktop.org/mobile-broadband/ModemManager/merge_requests/209/diffs?commit_id=93123d7665da1bd6b6765dfe92a71f2ff125d41f" rel="noreferrer" target="_blank">https://gitlab.freedesktop.org/mobile-broadband/ModemManager/merge_requests/209/diffs?commit_id=93123d7665da1bd6b6765dfe92a71f2ff125d41f</a>) 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. -- Aleksander <a href="https://aleksander.es" rel="noreferrer" target="_blank">https://aleksander.es</a> </blockquote></div>