> > 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 <aleksan...@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. > > -- > Aleksander > https://aleksander.es >
_______________________________________________ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
