The Xen framebuffer driver selects the xen keyboard driver, so the latter
will be built-in if XEN_FBDEV_FRONTEND=y. However, when CONFIG_INPUT
is a loadable module, this configuration cannot work. On mainline kernels,
the symbol will be enabled but not used, while in combination with
a patch I have to detect such useless configurations, we get the
expected link failure:
drivers/input/built-in.o: In function `xenkbd_remove':
xen-kbdfront.c:(.text+0x2f0): undefined reference to `input_unregister_device'
xen-kbdfront.c:(.text+0x30e): undefined reference to `input_unregister_device'
This changes the dependencies of XEN_FBDEV_FRONTEND so it cannot be
built-in if CONFIG_INPUT=m && CONFIG_INPUT_MISC=y, as that would result
in the broken select.
As usual, we would be much better off without the 'select', but removing
it now would likely break existing user configurations that depend on
it, so this adds another hack on top to get it working.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: 36c1132e34bd ("xen kconfig: fix select INPUT_XEN_KBDDEV_FRONTEND")
---
drivers/video/fbdev/Kconfig | 1 +
1 file changed, 1 insertion(+)
From: Andrew Jones <hidden> Date: 2016-02-12 13:56:51
On Fri, Feb 12, 2016 at 01:04:40PM +0100, Arnd Bergmann wrote:
quoted hunk
The Xen framebuffer driver selects the xen keyboard driver, so the latter
will be built-in if XEN_FBDEV_FRONTEND=y. However, when CONFIG_INPUT
is a loadable module, this configuration cannot work. On mainline kernels,
the symbol will be enabled but not used, while in combination with
a patch I have to detect such useless configurations, we get the
expected link failure:
drivers/input/built-in.o: In function `xenkbd_remove':
xen-kbdfront.c:(.text+0x2f0): undefined reference to `input_unregister_device'
xen-kbdfront.c:(.text+0x30e): undefined reference to `input_unregister_device'
This changes the dependencies of XEN_FBDEV_FRONTEND so it cannot be
built-in if CONFIG_INPUT=m && CONFIG_INPUT_MISC=y, as that would result
in the broken select.
As usual, we would be much better off without the 'select', but removing
it now would likely break existing user configurations that depend on
it, so this adds another hack on top to get it working.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: 36c1132e34bd ("xen kconfig: fix select INPUT_XEN_KBDDEV_FRONTEND")
---
drivers/video/fbdev/Kconfig | 1 +
1 file changed, 1 insertion(+)
CC'ing a few others.
On Fri, 12 Feb 2016, Arnd Bergmann wrote:
quoted hunk
The Xen framebuffer driver selects the xen keyboard driver, so the latter
will be built-in if XEN_FBDEV_FRONTEND=y. However, when CONFIG_INPUT
is a loadable module, this configuration cannot work. On mainline kernels,
the symbol will be enabled but not used, while in combination with
a patch I have to detect such useless configurations, we get the
expected link failure:
drivers/input/built-in.o: In function `xenkbd_remove':
xen-kbdfront.c:(.text+0x2f0): undefined reference to `input_unregister_device'
xen-kbdfront.c:(.text+0x30e): undefined reference to `input_unregister_device'
This changes the dependencies of XEN_FBDEV_FRONTEND so it cannot be
built-in if CONFIG_INPUT=m && CONFIG_INPUT_MISC=y, as that would result
in the broken select.
As usual, we would be much better off without the 'select', but removing
it now would likely break existing user configurations that depend on
it, so this adds another hack on top to get it working.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: 36c1132e34bd ("xen kconfig: fix select INPUT_XEN_KBDDEV_FRONTEND")
---
drivers/video/fbdev/Kconfig | 1 +
1 file changed, 1 insertion(+)
From: David Vrabel <hidden> Date: 2016-02-15 17:05:27
On 15/02/16 16:51, Stefano Stabellini wrote:
CC'ing a few others.
On Fri, 12 Feb 2016, Arnd Bergmann wrote:
quoted
The Xen framebuffer driver selects the xen keyboard driver, so the latter
will be built-in if XEN_FBDEV_FRONTEND=y. However, when CONFIG_INPUT
is a loadable module, this configuration cannot work. On mainline kernels,
the symbol will be enabled but not used, while in combination with
a patch I have to detect such useless configurations, we get the
expected link failure:
drivers/input/built-in.o: In function `xenkbd_remove':
xen-kbdfront.c:(.text+0x2f0): undefined reference to `input_unregister_device'
xen-kbdfront.c:(.text+0x30e): undefined reference to `input_unregister_device'
This changes the dependencies of XEN_FBDEV_FRONTEND so it cannot be
built-in if CONFIG_INPUT=m && CONFIG_INPUT_MISC=y, as that would result
in the broken select.
As usual, we would be much better off without the 'select', but removing
it now would likely break existing user configurations that depend on
it, so this adds another hack on top to get it working.
I would remove the select.
Existing configurations with both XEN_FBDEV_FRONTEND and
XEN_KBDDEV_FRONTEND will continue to work (since XEN_KBDEV_FRONTEND is
already enabled removing the select won't turn it off).
David
CC'ing a few others.
On Fri, 12 Feb 2016, Arnd Bergmann wrote:
quoted
The Xen framebuffer driver selects the xen keyboard driver, so the latter
will be built-in if XEN_FBDEV_FRONTEND=y. However, when CONFIG_INPUT
is a loadable module, this configuration cannot work. On mainline kernels,
the symbol will be enabled but not used, while in combination with
a patch I have to detect such useless configurations, we get the
expected link failure:
drivers/input/built-in.o: In function `xenkbd_remove':
xen-kbdfront.c:(.text+0x2f0): undefined reference to `input_unregister_device'
xen-kbdfront.c:(.text+0x30e): undefined reference to `input_unregister_device'
This changes the dependencies of XEN_FBDEV_FRONTEND so it cannot be
built-in if CONFIG_INPUT=m && CONFIG_INPUT_MISC=y, as that would result
in the broken select.
As usual, we would be much better off without the 'select', but removing
it now would likely break existing user configurations that depend on
it, so this adds another hack on top to get it working.
I would remove the select.
Existing configurations with both XEN_FBDEV_FRONTEND and
XEN_KBDDEV_FRONTEND will continue to work (since XEN_KBDEV_FRONTEND is
already enabled removing the select won't turn it off).
The Xen framebuffer driver selects the xen keyboard driver, so the latter
will be built-in if XEN_FBDEV_FRONTEND=y. However, when CONFIG_INPUT
is a loadable module, this configuration cannot work. On mainline kernels,
the symbol will be enabled but not used, while in combination with
a patch I have to detect such useless configurations, we get the
expected link failure:
drivers/input/built-in.o: In function `xenkbd_remove':
xen-kbdfront.c:(.text+0x2f0): undefined reference to `input_unregister_device'
xen-kbdfront.c:(.text+0x30e): undefined reference to `input_unregister_device'
This removes the extra "select", as it just causes more trouble than
it helps. In theory, some defconfig file might break if it has
XEN_FBDEV_FRONTEND in it but not INPUT_XEN_KBDDEV_FRONTEND. The Kconfig
fragment we ship in the kernel (kernel/configs/xen.config) however
already enables both, and anyone using an old .config file would
keep having both enabled.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Suggested-by: David Vrabel <redacted>
Fixes: 36c1132e34bd ("xen kconfig: fix select INPUT_XEN_KBDDEV_FRONTEND")
The Xen framebuffer driver selects the xen keyboard driver, so the latter
will be built-in if XEN_FBDEV_FRONTEND=y. However, when CONFIG_INPUT
is a loadable module, this configuration cannot work. On mainline kernels,
the symbol will be enabled but not used, while in combination with
a patch I have to detect such useless configurations, we get the
expected link failure:
drivers/input/built-in.o: In function `xenkbd_remove':
xen-kbdfront.c:(.text+0x2f0): undefined reference to `input_unregister_device'
xen-kbdfront.c:(.text+0x30e): undefined reference to `input_unregister_device'
This removes the extra "select", as it just causes more trouble than
it helps. In theory, some defconfig file might break if it has
XEN_FBDEV_FRONTEND in it but not INPUT_XEN_KBDDEV_FRONTEND. The Kconfig
fragment we ship in the kernel (kernel/configs/xen.config) however
already enables both, and anyone using an old .config file would
keep having both enabled.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Suggested-by: David Vrabel <redacted>
Fixes: 36c1132e34bd ("xen kconfig: fix select INPUT_XEN_KBDDEV_FRONTEND")
From: Tomi Valkeinen <hidden> Date: 2016-03-11 11:38:44
On 16/02/16 17:03, Arnd Bergmann wrote:
quoted hunk
The Xen framebuffer driver selects the xen keyboard driver, so the latter
will be built-in if XEN_FBDEV_FRONTEND=y. However, when CONFIG_INPUT
is a loadable module, this configuration cannot work. On mainline kernels,
the symbol will be enabled but not used, while in combination with
a patch I have to detect such useless configurations, we get the
expected link failure:
drivers/input/built-in.o: In function `xenkbd_remove':
xen-kbdfront.c:(.text+0x2f0): undefined reference to `input_unregister_device'
xen-kbdfront.c:(.text+0x30e): undefined reference to `input_unregister_device'
This removes the extra "select", as it just causes more trouble than
it helps. In theory, some defconfig file might break if it has
XEN_FBDEV_FRONTEND in it but not INPUT_XEN_KBDDEV_FRONTEND. The Kconfig
fragment we ship in the kernel (kernel/configs/xen.config) however
already enables both, and anyone using an old .config file would
keep having both enabled.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Suggested-by: David Vrabel <redacted>
Fixes: 36c1132e34bd ("xen kconfig: fix select INPUT_XEN_KBDDEV_FRONTEND")
No, that doesn't solve the problem:
If XEN_FBDEV_FRONTEND=y, INPUT=m and INPUT_MISC=y, we would still
get INPUT_XEN_KBDDEV_FRONTEND=y, which cannot work because of INPUT=m.
INPUT_MISC already depends on INPUT, so your change has no effect
at all.
Arnd
No, that doesn't solve the problem:
If XEN_FBDEV_FRONTEND=y, INPUT=m and INPUT_MISC=y, we would still
get INPUT_XEN_KBDDEV_FRONTEND=y, which cannot work because of INPUT=m.
INPUT_MISC already depends on INPUT, so your change has no effect
at all.
Please correct me if I am wrong, but the difference is that with this
change if INPUT=m, then the build system would ask the user whether she
wants to select INPUT_XEN_KBDDEV_FRONTEND as m or y, instead of
unconditionally set INPUT_XEN_KBDDEV_FRONTEND=y.
However it is true that if the users chooses
INPUT_XEN_KBDDEV_FRONTEND=y, then the problem persists.
Maybe we also need:
On Tuesday 16 February 2016 12:14:14 Stefano Stabellini wrote:
quoted
at all.
Please correct me if I am wrong, but the difference is that with this
change if INPUT=m, then the build system would ask the user whether she
wants to select INPUT_XEN_KBDDEV_FRONTEND as m or y, instead of
unconditionally set INPUT_XEN_KBDDEV_FRONTEND=y.
INPUT_XEN_KBDDEV_FRONTEND cannot be set by the user to 'y' if
INPUT=m, because of an implied dependency around the input/misc/Kconfig
file.
quoted hunk
However it is true that if the users chooses
INPUT_XEN_KBDDEV_FRONTEND=y, then the problem persists.
Maybe we also need:
Do you have a kernel config with INPUT=m that I can use to test with?
You can easily set that in any config if you disable CONFIG_VT. I don't
think it's worth spending more time on that, as everyone seems to be
happy with just removing the 'select', and I've sent a replacement
patch to do that.
Arnd