I fear that if we just pick i2c-thunderx, we'll just run into this problem again and again with new hosts. However, restricting i2c drivers to arm* seems reasonable. I'm unaware of any other archs that use the SSIF interface.
Note that using "uname -m" to figure out the architecture is nearly always a bad idea. Remember that there are all sorts of cases where the host kernel may not match the userspace - e.g. running i386 userspace on an x86_64 box, qemu-user emulation, etc. In this case, since the MAAS images are presumably always built on an x86 box, uname -m will never be "aarch64". I suggest using 'dpkg --print-architecture' instead.
The size increase for arm64 including all i2c/busses modules is 217K.
I fear that if we just pick i2c-thunderx, we'll just run into this problem again and again with new hosts. However, restricting i2c drivers to arm* seems reasonable. I'm unaware of any other archs that use the SSIF interface.
Note that using "uname -m" to figure out the architecture is nearly always a bad idea. Remember that there are all sorts of cases where the host kernel may not match the userspace - e.g. running i386 userspace on an x86_64 box, qemu-user emulation, etc. In this case, since the MAAS images are presumably always built on an x86 box, uname -m will never be "aarch64". I suggest using 'dpkg --print- architecture' instead.
The size increase for arm64 including all i2c/busses modules is 217K.