> > 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. 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. Cheers On Fri, Nov 15, 2019 at 8:10 AM Aleksander Morgado <aleksan...@aleksander.es> wrote: > Hey, > > Is there any benefit in keeping per-vendor plugins installed as > separate .so files and loaded during runtime? > > Does anyone know of any out-of-tree MM plugin out there? I would bet > there isn't any as we truly haven't kept a stable plugin API like > never ever. > > 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). > > What if we just simplify the setup and get all incorporated in the > daemon binary itself (for MM 1.14 for example)? > > -- > Aleksander > https://aleksander.es > _______________________________________________ > ModemManager-devel mailing list > ModemManager-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
_______________________________________________ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
