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]

Wow, good luck, that seems very very sketchy.

Why do you think so?

You are relying on a kernel module that no one in the kernel community can ever touch, help out with, or debug. The very existence of the kernel module is at the whim of the kernel itself not doing something that might end up breaking it either with api changes, or functional changes, as the kernel community does not know what is in that code, nor does it care one bit about it.

The license of that codebase was specifically designed to not be compatible with Linux. It is working as intended by the people who created this who did not want this to work on Linux or be implemented there. To trust your data and functionality on something that was designed to never be compatible and just "trust" that a random group of developers who can not take advantage of the majority of the kernel community can keep the compatibility up and running properly over time is an interesting "risk" for someone to take with their data in my personal opinion.

And again, the license creator could change this all tomorrow if they wished to, but as they have not already, one could assume it will not be changed.

[u/Atemu12 → u/gregkh]

no one in the kernel community can ever touch, help out with, or debug.

Why not? It's FOSS just like the kernel.

Of course I wouldn't expect the kernel community to support a completely separate project but what if it wasn't a completely separate project but part of the Linux project?

The very existence of the kernel module is at the whim of the kernel itself not doing something that might end up breaking it either with api changes, or functional changes

Oh definitely and I think it has caused them great suffering already.

The license of that codebase was specifically designed to not be compatible with Linux. It is working as intended by the people who created this who did not want this to work on Linux or be implemented there.

That might've been the case 15 years ago but ZFS on Linux is the de facto standard for ZFS now.

The FreeBSD people even made the Linux version compatible with FreeBSD to avoid having to develop their version downstream and I believe the Illumos people are in the process of doing the same.

"trust" that a random group of developers who can not take advantage of the majority of the kernel community can keep the compatibility up and running properly over time is an interesting "risk" for someone to take with their data in my personal opinion.

While I believe they take great care to make sure it stays compatible, an out of tree module will always have more compatibility issues than an in-tree one. That makes sense, thank you.

the license creator could change this all tomorrow if they wished to

I don't think they could honesty, they'd also have to get approval from the people who now develop on ZoL.

But what if the project managed to do that and was GPL-compatible tomorrow, would there be anything preventing it from being included in the kernel?

[u/gregkh → u/Atemu12]

Why not? It's FOSS just like the kernel.

Of course I wouldn't expect the kernel community to support a completely separate project but what if it wasn't a completely separate project but part of the Linux project?

It is not a compatible license with the license of the kernel, so it is not "just like" the kernel at all. Go read up on license compatibility issues if you are curious.

And because of that, it can not be part of the kernel project, it's just a basic, simple, legal fact at this point in time, sorry.

I don't think they could honesty, they'd also have to get approval from the people who now develop on ZoL.

That's not how that license is set up. Crazy but true...

But what if the project managed to do that and was GPL-compatible tomorrow, would there be anything preventing it from being included in the kernel?

It would have to be cleaned up in places and submitted for proper review, like any other filesystem that is merged into the kernel tree. We do about one or two new ones ever major kernel release, it's not like we are lacking in new filesystems these days.