Re: Built-in plugins?
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 > 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
Re: Built-in plugins?
> > 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 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. >
Re: Built-in plugins?
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
Re: Built-in plugins?
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
Re: Built-in plugins?
>> 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. -- Aleksander https://aleksander.es ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: Built-in plugins?
> > 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)? > > It seems OK, but what's the size difference of MM binary with no > plugins, and with all plugins? > No real idea until that is implemented, but if my numbers are more or less approx, I'd say that we could go from (e.g. in my host setup) 6.5MB daemon + 7MB plugins to 12MB daemon (so around ~2MB less). But a proper plugin setup with new modules providing the shared stuff would gain us the same amount of space, and that is probably also a good idea. See my next reply to Matthew. -- Aleksander https://aleksander.es ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: Built-in plugins?
On Fri, 2019-11-15 at 16:10 +0100, Aleksander Morgado 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)? It seems OK, but what's the size difference of MM binary with no plugins, and with all plugins? Dan ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Built-in plugins?
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
