On Thu, Apr 29, 2021 at 04:10:09PM -0400, Phillip Susi wrote:

It appears that input/input.c is responsible for the insane modalias
length.  If I am reading input_print_modalias() correctly, it appends a
"k" plus every key code that the keyboard supports,

Not every keyboard, but all keycodes above KEY_MIN_INTERESTING which is
KEY_MUTE, so that interested handlers could match on devices they are
interested in without first opening them or poking through sysfs.

and the Xen Virtual
Keyboard supports a lot of keycodes.  Why does it do this?

I don't know why Xen keyboard exports that many keycodes ;) In general,
my recommendation is to mirror the physical device when possible, and
instantiate several devices so there is 1:1 relationship between virtual
and physical devices.

In cases where it is not feasible, we need to be more careful about
declaring capabilities. For xen-kbdfront I do not think the keyboard
portion should be declaring keys from the various BTN_* ranges.

 
Phillip Susi writes:

quoted

So I have finally drilled down to the modalias for the Xen Virtual
Keyboard driver being so long ( over 2KB ) that it causes an -ENOMEM
when trying to add it to the environment for uevents.  This causes
coldplug to fail, which causes the script doing coldplug as part of the
debian-installer init to fail, which causes a kernel panic when init
exits, which then for reasons I have yet to understand, causes the Xen
domU to reboot.

Why is this modalias so huge?  Can we pare it down, or or is there
another solution to get uevents working on this device again?  Maybe the
environment block size needs to be increased?  I don't know.

Thanks.

-- 
Dmitry