4 ms·

Brillo Common Kernel

37 points by cpeterso 10y ago

wmf 10y ago
One wonders if this will suddenly make embedded companies non-incompetent or if they will just not use Brillo.
dmitrygr 10y ago
A noble goal, but good luck doing this with a QCOM kernel :(
nextos 10y ago
I guess this would be fantastic for alternate ROMs like CopperheadOS, as they would be freed from the burden of testing on many devices.
- aorth 10y ago
  It would even be nice to have a more modern kernel on regular AOSP Nexuses, not just alternative ROMs! But I'm not entirely sure this is for phones. Brillo itself places more emphasis "embedded" and "internet of things". https://developers.google.com/brillo/ https://developers.google.com/brillo/
IshKebab 10y ago
This just isn't going to work as long as there isn't a sane way to distribute Linux drivers.
- TD-Linux 10y ago
  Yes there is - in the kernel tree. Works great for my desktop and laptop.
  - IshKebab 10y ago
    That's not a good solution in general. * You can't distribute closed-source drivers. I wish everything was open source as much as the next guy but let's be realistic. Imagine if all Linux user-space software had to be open source! * You can't release drivers at the same time as your hardware. You have to get your drivers into the kernel years before you release the hardware, otherwise nothing will support it out of the box. This is obviously idiotic development-wise, but it also leaks product releases. * It's extra effort to get drivers into the tree. Despite what the kernel developers say they clearly won't accept every driver. They might not like your architecture or code style, it might be too niche, etc. It's another annoying barrier. * Fairly obviously it doesn't scale well. What happens in 2030 when the Linux kernel contains 100000 drivers, or whatever? Of course there are downsides to a stable ABI - you have to maintain backwards compatibility, it might encourage closed source drivers... but it's easily worth, especially on mobile.
- derefr 10y ago
  It's very interesting to watch the various workarounds to the lack of Linux ABI that have become more-or-less "production stable" over the years. The smoothest one I know about is the "open-vm-tools" apt package (the FOSS version of the "VMWare Tools" guest paravirtualization drivers.) The package depends on build-essential and dkms and linux-headers, and installing it just automatically makes some new .ko files pop up in /lib/modules without so much as a hiccup in syslog. (This, compared to the old vendored route, where upgrading the kernel meant everything broke until a new version of the tools came out.) Having everything at the distro level is a brilliant solution, because the distro can keep their kernel-package and driver-packages in sync and compatible. Of course, it'd be much nicer if the kernel would just accept drivers like this into the tree, but sometimes (like in this case, where it's a third-party basically "making up" drivers to talk to their own new features) it just doesn't make sense.

37 points by cpeterso 10y ago

wmf 10y ago

One wonders if this will suddenly make embedded companies non-incompetent or if they will just not use Brillo.

dmitrygr 10y ago

A noble goal, but good luck doing this with a QCOM kernel :(

nextos 10y ago

I guess this would be fantastic for alternate ROMs like CopperheadOS, as they would be freed from the burden of testing on many devices.

aorth 10y ago
It would even be nice to have a more modern kernel on regular AOSP Nexuses, not just alternative ROMs! But I'm not entirely sure this is for phones. Brillo itself places more emphasis "embedded" and "internet of things". https://developers.google.com/brillo/ https://developers.google.com/brillo/

IshKebab 10y ago

This just isn't going to work as long as there isn't a sane way to distribute Linux drivers.

TD-Linux 10y ago
Yes there is - in the kernel tree. Works great for my desktop and laptop.
- IshKebab 10y ago
  That's not a good solution in general. * You can't distribute closed-source drivers. I wish everything was open source as much as the next guy but let's be realistic. Imagine if all Linux user-space software had to be open source! * You can't release drivers at the same time as your hardware. You have to get your drivers into the kernel years before you release the hardware, otherwise nothing will support it out of the box. This is obviously idiotic development-wise, but it also leaks product releases. * It's extra effort to get drivers into the tree. Despite what the kernel developers say they clearly won't accept every driver. They might not like your architecture or code style, it might be too niche, etc. It's another annoying barrier. * Fairly obviously it doesn't scale well. What happens in 2030 when the Linux kernel contains 100000 drivers, or whatever? Of course there are downsides to a stable ABI - you have to maintain backwards compatibility, it might encourage closed source drivers... but it's easily worth, especially on mobile.
derefr 10y ago
It's very interesting to watch the various workarounds to the lack of Linux ABI that have become more-or-less "production stable" over the years. The smoothest one I know about is the "open-vm-tools" apt package (the FOSS version of the "VMWare Tools" guest paravirtualization drivers.) The package depends on build-essential and dkms and linux-headers, and installing it just automatically makes some new .ko files pop up in /lib/modules without so much as a hiccup in syslog. (This, compared to the old vendored route, where upgrading the kernel meant everything broke until a new version of the tools came out.) Having everything at the distro level is a brilliant solution, because the distro can keep their kernel-package and driver-packages in sync and compatible. Of course, it'd be much nicer if the kernel would just accept drivers like this into the tree, but sometimes (like in this case, where it's a third-party basically "making up" drivers to talk to their own new features) it just doesn't make sense.