To make new tools that depend on it like schedqos [1] more reliable, it
is important to ensure users can find it by default on all system.

[1] https://lore.kernel.org/lkml/20260415000910.2h5misvwc45bdumu@airbuntu/

Signed-off-by: Qais Yousef <qyousef@layalina.io>
---
 drivers/connector/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/connector/Kconfig b/drivers/connector/Kconfig
index 0c2d2aa82d8c..bad247d47146 100644
--- a/drivers/connector/Kconfig
+++ b/drivers/connector/Kconfig
@@ -3,6 +3,7 @@
 menuconfig CONNECTOR
 	tristate "Connector - unified userspace <-> kernelspace linker"
 	depends on NET
+	default y
 	help
 	  This is unified userspace <-> kernelspace connector working on top
 	  of the netlink socket protocol.
-- 
2.34.1

On Sun, 19 Apr 2026 22:42:17 +0100 Qais Yousef wrote:
> To make new tools that depend on it like schedqos [1] more reliable, it
> is important to ensure users can find it by default on all system.

If scheduler maintainers think this is appropriate they should take
this patch via their tree (please). connector falls under networking 
for historical reasons (it's Netlink based) but we lack the context
necessary to apply a "default y" patch of this nature.

default y should be used if the symbol is necessary for most Linux
users across use cases and architectures. It's not obvious to me
that that is the case here. The commit message links to a tool 
which is less than a week old?

+Ingo and Peter

On 04/20/26 13:18, Jakub Kicinski wrote:
> On Sun, 19 Apr 2026 22:42:17 +0100 Qais Yousef wrote:
> > To make new tools that depend on it like schedqos [1] more reliable, it
> > is important to ensure users can find it by default on all system.
> 
> If scheduler maintainers think this is appropriate they should take
> this patch via their tree (please). connector falls under networking 
> for historical reasons (it's Netlink based) but we lack the context
> necessary to apply a "default y" patch of this nature.

I see, I didn't add them, but I'll resend with them added.

> 
> default y should be used if the symbol is necessary for most Linux
> users across use cases and architectures. It's not obvious to me

Hmm I am not aware of such rules. It should be generally is useful and doesn't
have a drawback - which what I understood this is. What is the cost of enabling
this? This seems widely enabled feature by distro in general.

> that that is the case here. The commit message links to a tool 
> which is less than a week old?

It is chicken an egg. We want to add sched qos support and it relies on netlink
to monitor tasks as they are created and tag them with QoS. If we can't make
sure this is available on all systems by default (ie: users must consciously
opt-out of this option), we will end up with inconsistencies.

I've hit this when we added UCLAMP and it took debian two years (approx) to
decide to enable it by default after making a feature request.