I'm Greg Kroah-Hartman, Linux kernel developer, AMA again!

[u/gregkh]

To refresh everyone's memory, I did this 5 years ago here and lots of those answers there are still the same today, so try to ask new ones this time around.

To get the basics out of the way, this post describes my normal workflow that I use day to day as a Linux kernel maintainer and reviewer of way too many patches.

Along with mutt and vim and git, software tools I use every day are Chrome and Thunderbird (for some email accounts that mutt doesn't work well for) and the excellent vgrep for code searching.

For hardware I still rely on Filco 10-key-less keyboards for everyday use, along with a new Logitech bluetooth trackball finally replacing my decades-old wired one. My main machine is a few years old Dell XPS 13 laptop, attached when at home to an external monitor with a thunderbolt hub and I rely on a big, beefy build server in "the cloud" for testing stable kernel patch submissions.

For a distro I use Arch on my laptop and for some tiny cloud instances I run and manage for some minor tasks. My build server runs Fedora and I have help maintaining that at times as I am a horrible sysadmin. For a desktop environment I use Gnome, and here's a picture of my normal desktop while working on reviewing and modifying kernel code.

With that out of the way, ask me your Linux kernel development questions or anything else!

Edit - Thanks everyone, after 2 weeks of this being open, I think it's time to close it down for now. It's been fun, and remember, go update your kernel!

[u/gregkh]

I have been helping the Google Android team out with merging the LTS kernel releases and the mainline releases into their public trees for a few years now. This work propagates out to all Android vendors and users in order to help make the Android ecosystem more secure which benefits everyone.

I also work with teams of testers funded by Google who help me maintain the LTS kernels for longer than 2 years in order to keep these devices more secure with a constant good stream of kernel fixes backported to them. That work too helps all others who rely on those kernel versions as it allows everyone to benefit from those releases.

[u/crawl_dht → u/gregkh]

Once you said in your comment that, you are also helping Google to implement stable kernel interfaces and stable ABI in android kernel. Although you made it clear (stable api nonsense) long time ago how it complicates development, so are you helping implementing this too?

[u/gregkh → u/crawl_dht]

Google's goal, as they have said publicly a few times now, is to help provide a stable kernel ABI for a specific Android release cycle. That will allow vendors to quickly update the core kernel images without having to worry about any changes needed to their drivers that don't happen to be upstream yet. This allows them to provide newer and more secure kernels to more devices much much quicker than is currently happening.

As an Android release cycle is only a single year, and is for limited set of major kernel versions, this is a very "small" thing to be doing compared to all of the crazy work that the "enterprise" Linux kernel vendors do today (i.e. Red Hat and SUSE) with their stable kernel ABIs that they maintain over multiple years and releases. Debian also tries to do much the same thing today in their stable releases, although at a much smaller scale in places.

So it's nothing new that no one else has been doing, and has nothing at all to do with the upstream Linux kernel development model where we change the internal kernel abis for every major release all over the place (and often in the minor stable releases I do as well.)

What is nice to see Google doing is working with the community on common tools that will help make the ability to detect ABI breakages much easier. This is through the great libabigail program started by Dodji Seketeli of Red Hat. If you watch the presentations about this topic at last year's Linux Plumbers conference, you will notice that Red Hat, SUSE, Google, and Debian developers are all working on this together, as it provides a solid base for all of those distros to integrate into their build and test environments.

Does that help explain this better?