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