On Sun, 2019-11-17 at 15:16 +0100, Aleksander Morgado wrote: > > > 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. Dan _______________________________________________ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
