| Message ID | 20240116-rm-ext-plugins-v1-0-62990fb07369@gmail.com |
|---|---|
| Headers | show |
| Series | Remove support for external plugins | expand |
Hi Emil, On Tue, Jan 16, 2024 at 9:19 AM Emil Velikov via B4 Relay <devnull+emil.l.velikov.gmail.com@kernel.org> wrote: > > Greetings one and all, > > In this series, we prune support for external plugins and cleanup the > associated code. The inspiration here is multiple-fold: > - the plugins are under linked - generally a bad idea > - the plugins use undefined, unscoped, unversioned internal API > - the main daemons expose their internal API increasing their size Im not so sure I want to remove the external plugins support completely, but I do understand that normally distros don't really want to have it enabled in production due to the reasons mentioned above, but I think we could find a middle ground here by disabling it by default but still let systems to re-enable it if they have some custom plugin that they may still want to use as external plugin. > So this series: > - bluetoothd: removes the "dummy" external plugin > - bluetoothd: converts the sixaxis plugin to builtin > - bluetoothd, obexd: removes support for external plugins > - bluetoothd, obexd: cleans the exported symbols by the daemons > - android: (bonus) export only the required HMI plugin entrypoint > > Please note: > - expect minor conflicts wrt my earlier patches - happy to respin > - there _might_ be third-party external plugins, that my distro search > have missed > > This concludes the paper cut patches. Expect some more around config > file handling in the upcoming days :-) > > Thanks > Emil > > --- > Emil Velikov (8): > obexd: remove support for external plugins > build: don't export internal obexd API > plugins: remove external-dummy > plugins: convert external sixaxis plugin to builtin > bluetoothd: remove support for external plugins > bluetoothd: remove debug support for external plugins > bluetoothd: don't export internal API > android: export only (android) entrypoint from the modules > > Makefile.am | 21 +------------- > Makefile.obexd | 8 ++---- > Makefile.plugins | 8 ++---- > android/Makefile.am | 3 ++ > android/hal-audio.c | 1 + > android/hal-bluetooth.c | 1 + > android/hal-sco.c | 1 + > obexd/src/obexd.h | 2 +- > obexd/src/plugin.c | 73 ++++------------------------------------------- > obexd/src/plugin.h | 9 ------ > plugins/external-dummy.c | 28 ------------------ > src/bluetooth.ver | 20 ------------- > src/btd.h | 2 +- > src/log.c | 10 ++----- > src/log.h | 3 +- > src/plugin.c | 74 ++++-------------------------------------------- > src/plugin.h | 16 ----------- > 17 files changed, 30 insertions(+), 250 deletions(-) > --- > base-commit: 770ad5614e7e8074133e6f563495ce4822f63fe4 > change-id: 20240116-rm-ext-plugins-ba0b852a492b > > Best regards, > -- > Emil Velikov <emil.l.velikov@gmail.com> > >
On Mon, 22 Jan 2024 at 18:35, Luiz Augusto von Dentz <luiz.dentz@gmail.com> wrote: > > Hi Emil, > > On Tue, Jan 16, 2024 at 9:19 AM Emil Velikov via B4 Relay > <devnull+emil.l.velikov.gmail.com@kernel.org> wrote: > > > > Greetings one and all, > > > > In this series, we prune support for external plugins and cleanup the > > associated code. The inspiration here is multiple-fold: > > - the plugins are under linked - generally a bad idea > > - the plugins use undefined, unscoped, unversioned internal API > > - the main daemons expose their internal API increasing their size > > Im not so sure I want to remove the external plugins support > completely, but I do understand that normally distros don't really > want to have it enabled in production due to the reasons mentioned > above, but I think we could find a middle ground here by disabling it > by default but still let systems to re-enable it if they have some > custom plugin that they may still want to use as external plugin. > Thanks for the feedback. Sure, I can convert this to a "configure --support-external-plugins", where all the presently removed code will be compiled out. Still not entirely sure how external plugins are supposed to work, considering the API/ABI mentioned earlier - any pointers? Do you know of any example plugins that you can mention? -Emil
Hi Emil, On Tue, Jan 23, 2024 at 8:54 AM Emil Velikov <emil.l.velikov@gmail.com> wrote: > > On Mon, 22 Jan 2024 at 18:35, Luiz Augusto von Dentz > <luiz.dentz@gmail.com> wrote: > > > > Hi Emil, > > > > On Tue, Jan 16, 2024 at 9:19 AM Emil Velikov via B4 Relay > > <devnull+emil.l.velikov.gmail.com@kernel.org> wrote: > > > > > > Greetings one and all, > > > > > > In this series, we prune support for external plugins and cleanup the > > > associated code. The inspiration here is multiple-fold: > > > - the plugins are under linked - generally a bad idea > > > - the plugins use undefined, unscoped, unversioned internal API > > > - the main daemons expose their internal API increasing their size > > > > Im not so sure I want to remove the external plugins support > > completely, but I do understand that normally distros don't really > > want to have it enabled in production due to the reasons mentioned > > above, but I think we could find a middle ground here by disabling it > > by default but still let systems to re-enable it if they have some > > custom plugin that they may still want to use as external plugin. > > > > Thanks for the feedback. Sure, I can convert this to a "configure > --support-external-plugins", where all the presently removed code will > be compiled out. > > Still not entirely sure how external plugins are supposed to work, > considering the API/ABI mentioned earlier - any pointers? Do you know > of any example plugins that you can mention? Not really, well just the sixaxis but that can be converted to be built-in, but that being external means that there could be external plugins we don't know about thus why I think we would be better to have a flag to re-enable them just in case. Anyway I think for sixaxis we could just have it as built-in since it seems popular enough with the likes of steam deck, etc. > -Emil
On Tue, 23 Jan 2024 at 14:00, Luiz Augusto von Dentz <luiz.dentz@gmail.com> wrote: > > Hi Emil, > > On Tue, Jan 23, 2024 at 8:54 AM Emil Velikov <emil.l.velikov@gmail.com> wrote: > > > > On Mon, 22 Jan 2024 at 18:35, Luiz Augusto von Dentz > > <luiz.dentz@gmail.com> wrote: > > > > > > Hi Emil, > > > > > > On Tue, Jan 16, 2024 at 9:19 AM Emil Velikov via B4 Relay > > > <devnull+emil.l.velikov.gmail.com@kernel.org> wrote: > > > > > > > > Greetings one and all, > > > > > > > > In this series, we prune support for external plugins and cleanup the > > > > associated code. The inspiration here is multiple-fold: > > > > - the plugins are under linked - generally a bad idea > > > > - the plugins use undefined, unscoped, unversioned internal API > > > > - the main daemons expose their internal API increasing their size > > > > > > Im not so sure I want to remove the external plugins support > > > completely, but I do understand that normally distros don't really > > > want to have it enabled in production due to the reasons mentioned > > > above, but I think we could find a middle ground here by disabling it > > > by default but still let systems to re-enable it if they have some > > > custom plugin that they may still want to use as external plugin. > > > > > > > Thanks for the feedback. Sure, I can convert this to a "configure > > --support-external-plugins", where all the presently removed code will > > be compiled out. > > > > Still not entirely sure how external plugins are supposed to work, > > considering the API/ABI mentioned earlier - any pointers? Do you know > > of any example plugins that you can mention? > > Not really, well just the sixaxis but that can be converted to be > built-in, but that being external means that there could be external > plugins we don't know about thus why I think we would be better to > have a flag to re-enable them just in case. Anyway I think for sixaxis > we could just have it as built-in since it seems popular enough with > the likes of steam deck, etc. > Ack, much appreciated. Will send v2 shortly. Emil
Greetings one and all, In this series, we prune support for external plugins and cleanup the associated code. The inspiration here is multiple-fold: - the plugins are under linked - generally a bad idea - the plugins use undefined, unscoped, unversioned internal API - the main daemons expose their internal API increasing their size So this series: - bluetoothd: removes the "dummy" external plugin - bluetoothd: converts the sixaxis plugin to builtin - bluetoothd, obexd: removes support for external plugins - bluetoothd, obexd: cleans the exported symbols by the daemons - android: (bonus) export only the required HMI plugin entrypoint Please note: - expect minor conflicts wrt my earlier patches - happy to respin - there _might_ be third-party external plugins, that my distro search have missed This concludes the paper cut patches. Expect some more around config file handling in the upcoming days :-) Thanks Emil --- Emil Velikov (8): obexd: remove support for external plugins build: don't export internal obexd API plugins: remove external-dummy plugins: convert external sixaxis plugin to builtin bluetoothd: remove support for external plugins bluetoothd: remove debug support for external plugins bluetoothd: don't export internal API android: export only (android) entrypoint from the modules Makefile.am | 21 +------------- Makefile.obexd | 8 ++---- Makefile.plugins | 8 ++---- android/Makefile.am | 3 ++ android/hal-audio.c | 1 + android/hal-bluetooth.c | 1 + android/hal-sco.c | 1 + obexd/src/obexd.h | 2 +- obexd/src/plugin.c | 73 ++++------------------------------------------- obexd/src/plugin.h | 9 ------ plugins/external-dummy.c | 28 ------------------ src/bluetooth.ver | 20 ------------- src/btd.h | 2 +- src/log.c | 10 ++----- src/log.h | 3 +- src/plugin.c | 74 ++++-------------------------------------------- src/plugin.h | 16 ----------- 17 files changed, 30 insertions(+), 250 deletions(-) --- base-commit: 770ad5614e7e8074133e6f563495ce4822f63fe4 change-id: 20240116-rm-ext-plugins-ba0b852a492b Best regards,