4 ms·

are you sure the problem is arm? How can google use a standard kernel version? I mean it is quite standard and only changes between major releases doesn't it? T

by untoreh 10y ago

are you sure the problem is arm? How can google use a standard kernel version? I mean it is quite standard and only changes between major releases doesn't it? The thing is that linux being monolithic requires all the drivers baked in, which is fine like it is fine the whole flashing ROMs stuff, or maybe it was a few years a go when phones where phones and not pocket pcs so they benefited from the whole packaging. Magenta by google seems to use userspace drivers, so if that is ever gonna get used in phones it might be a solution for a more standard kernel

adrianratnapala 10y ago
I don't see what the monolithic kernel has to do with it. Kernel modules are dynamically have been loadable. Yes, they run in kernel mode, and yes their version tightly bound to the running kernel -- but how is that a problem for abstracting of varying hardware?
djsumdog 10y ago
Linux modules are very kernel specific. If you have modules compiled against the same kernel version, but with slightly differently flags, you won't be able to load it and will get a lot of invalid symbols. There are thousands of kernel variants between every Linux distro. You always need to recompile drivers. nVidida and AMD/ATI get by this by providing binary blobs and a shim layer than can compile and link the two. In the Windows/Mac world there is one version of the kernel officially maintained and distributed by their respective companies. They can keep the kernel consistent for a given release. That's what you have one set of drivers for Windows 7, one for 8 and one for 10, instead of a different set of drivers for each and every service pack. Android could, at a minimum, standardize the kernel for every Android version. With that, binary drivers could work across devices.
vetinari 10y ago
Yes, the problem is ARM. How do you want to boot your kernel? There is no BIOS or UEFI or other standardized firmware, that would initialize at least one CPU, RAM, storage and load your kernel from there. Every ARM implementation boots in different way. After you boot up, how do you enumerate devices that your kernel can use? There is no PCIE or other plug and play bus, that can enumerate attached devices. Your OS has to know what is available. Poke a wrong port and your board freezes. This is the reason, why Device Tree is a thing. Linux kernel does not require all drivers baked in - kernel modules existed for decades already. Monolithic does not mean that everything is one big blob. NT is also monolithic, for example.

by untoreh 10y ago

adrianratnapala 10y ago

I don't see what the monolithic kernel has to do with it. Kernel modules are dynamically have been loadable. Yes, they run in kernel mode, and yes their version tightly bound to the running kernel -- but how is that a problem for abstracting of varying hardware?

djsumdog 10y ago

Linux modules are very kernel specific. If you have modules compiled against the same kernel version, but with slightly differently flags, you won't be able to load it and will get a lot of invalid symbols. There are thousands of kernel variants between every Linux distro. You always need to recompile drivers. nVidida and AMD/ATI get by this by providing binary blobs and a shim layer than can compile and link the two. In the Windows/Mac world there is one version of the kernel officially maintained and distributed by their respective companies. They can keep the kernel consistent for a given release. That's what you have one set of drivers for Windows 7, one for 8 and one for 10, instead of a different set of drivers for each and every service pack. Android could, at a minimum, standardize the kernel for every Android version. With that, binary drivers could work across devices.

vetinari 10y ago

Yes, the problem is ARM. How do you want to boot your kernel? There is no BIOS or UEFI or other standardized firmware, that would initialize at least one CPU, RAM, storage and load your kernel from there. Every ARM implementation boots in different way. After you boot up, how do you enumerate devices that your kernel can use? There is no PCIE or other plug and play bus, that can enumerate attached devices. Your OS has to know what is available. Poke a wrong port and your board freezes. This is the reason, why Device Tree is a thing. Linux kernel does not require all drivers baked in - kernel modules existed for decades already. Monolithic does not mean that everything is one big blob. NT is also monolithic, for example.