When you move from one component to another, it's as simple as installing a driver and everything will just work.
I understand that a challenge with ARM SoCs is that chip makers need to create complete OS releases that contain all of the drivers for that SoC/it's embedded components.
This means that despite a device having the same GPU or NIC as another device, there isn't an easy way to take the drivers for the known devices and putting them on another (similar) OS.
A few examples:
Despite running a linux kernel, an Android phone can't have the hardware drivers extracted from its ROM and then dropped on another Linux based OS. e.g. you can't run the ARM build of Ubuntu on a phone.
Despite running a linux OS and being an open platform, you can't "just" run any distro on a Raspberry Pi.
Similarly, Microsoft doesn't provide an ISO for ARM Windows because you need to have the drivers ready to go before you boot. This means the conventional installation method of Windows doesn't make sense in the context of an ARM device.
Any reason we don't have a more generalised and modular approach to Arm drivers?
That interoperability exists because Microsoft holds sole control of what the definition of a Windows compatible x86 computer is through its Windows Hardware Compatibility Program: https://docs.microsoft.com/en-us/windows-hardware/design/com... All free operating systems running on commodity x86 laptops, PCs, and servers ride on the coattails of this platform standardization.
Microsoft does not have an equivalent for ARM, nor do any of the big names in ARM processors/systems want them to, largely because they all dream of being the one holding the same (lucrative) level of control someday themselves.
Not sure what you mean. For SoC components, the drivers might be provided by the vendor of the ARM SoC. But there still are drivers -- the OS still needs to talk to the SSD (via a driver), USB peripherals (via a class compliant driver and/or custom drivers), and so on. We might not get to install a driver for the GPU, because it's a custom design and the vendor of the machine (eg. Apple for M1) has already taken care of it.
But if we are to install any kind of third party peripheral (sound interfaces, printers, etc) with custom options (not just satisfied with generic class compliant driver) we'll need to install a driver.