Linus Torvalds Comments On Bcachefs Prospects For Linux 6.6

A few days ago Bcachefs was proposed for inclusion to Linux 6.6 after it failed to be pulled for the prior Linux 6.5 kernel cycle. Since then we've been waiting to see what action Linus Torvalds would take with including Bcachefs... He's finally commented on it today but remains to be seen if it will land for this kernel release.

Since the Bcachefs pull request was sent out a few days ago, there's been some recent kernel developer discussions whether Bcachefs should make use of IOmap or not. But it doesn't appear that's a blocker and not all upstream developers are in agreement whether IOmap is even a good fit.

But Torvalds has now chimed in and pointed out an immediate blocker that the pull request isn't making use of a signed Git tag with a PGP key with a chain of trust. Without that, Linus Torvalds simply won't accept the code. That though should be relatively easy and quick to overcome with that being expected of Linux subsystem/driver maintainers to use signed Git tags.

Linus Torvalds though then went on to write about his concerns around Bcachefs maintainer Kent Overstreet working with the upstream kernel developers and how in many past kernel mailing list discussions they have evolved into arguments and a lot of friction. There's also the matter that the Bcachefs code was never vetted by living in linux-next for a while. Torvalds wrote:

"There are a few other issues that I have with this, and Christoph did mention a big one: it's not been in linux-next. I don't know why I thought it had been, it's just such an obvious thing for any new "I want this merged upstream" tree.

So these kinds of "I'll just ignore _all_ basic rules" kinds of issues do annoy me.

I need to know that you understand that if you actually want this upstream, you need to work with upstream.

That very much means *NOT* continuing this "I'll just do it my way". You need to show that you can work with others, that you can work within the framework of upstream, and that not every single thread you get into becomes an argument.

This, btw, is not negotiable. If you feel uncomfortable with that basic notion, you had better just continue doing development outside the main kernel tree for another decade.

The fact that I only now notice that you never submitted this to linux-next is obviously on me. My bad.

But at the same time it worries me that it might be a sign of you just thinking that your way is special."

Linus added in another post about hitting a compiler error, something that could have been more easily caught via the vetting in linux-next. In that post he added:

"As it is, I'm not convinced I want to even continue to go through this all, when it fails at the very first hurdle. A clean build is not some "would be nice" feature, and it is big part of why we have automation for new code."

So at this stage it's still not clear yet if Bcachefs will be merged this week for the Linux 6.6 cycle.