[Bloat] [Cerowrt-devel] wireguard almost takes a bullet

[Theodore Ts'o]

On Mon, Mar 29, 2021 at 04:28:11PM -0400, David P. Reed wrote:
> 
>  
> What tends to shape Linux and FreeBSD, etc. are the money sources
> that flow into the communities. Of course Linux is quite
> independently wealthy now. The senior executives of the Linux
> Foundation are paid nearly a million dollars a year, each.  Which
> just indicates that major corporations are seriously interested in
> controlling the evolution of Linux (not the Gnu part, the part that
> has Linus Torvalds at its center).

First of all, I don't believe your salary numbers are correct.

https://nonprofitlight.com/ca/san-francisco/linux-foundation

Secondly, the "senior executives" of the Linux Foundation don't have
any control over "the evolution of Linux".  The exception to that are
the "Fellows" (e.g., Linus Torvalds, Greg K-H, etc.) and I can assure
you that they don't take orders from Jim Zemlin, the executive
director, or any one else at the Linux Foundation.

The senior developers of Linux do tend to work for the big
corporations, but culturally, we do try to keep our "corporate hats"
and our "community" hats quite separate, and identify when we our
company hats on.  Many senior developers have transitioned between
multiple companies, and over time, it's been understood that their
primarily allegiance is to Linux, and not to the company.  In fact,
the primary job of maintainers is to say "no" to companies when they
try to push crap code into the kernel.  And that's because it's the
maintainer's responsibility to clean up the mess if they say yes to
code that's Just Not Ready, since they have a long-term responsbility
towards their subsystem, unlike engineers or contractors that only
have a short-term goal to get the code upstream.

This is where having a hierarchial ownership model IMHO works better
than a "core team" model where there can be a diffusion of
responsibility, where anyone with a commit bit can commit anywhere in
the OS.  In contrast, David Miller "owns" the networking area, and so
someone who might be, say, the ext4 or xfs maintainer does not have
the right (read: Linus will reject a pull request from me if I try to
change code in the networking stack with out DaveM's signoff) to
change code outside of their subsystem.

So you're right that Linus probably doesn't know or care about
bufferbloat.  He's delegated pretty much all networking issues to
David Miller as the networking czar, and within networking, David
Miller has his submaintainers with different specialities.  This does
get complicated when there are changes which cross subsystems.  For
example, before Wireguard could land in the kernel, there were changes
needed in both the crypto and networking layers, and Jason had to
negotiate with multiple senior developers in those subsystems, and the
code was subject to quite a lot of review before it could land.  (It
took months, and we didn't try to rush things before a major
release....)

> I just spent 9 months trying to get a very tiny fix to the Linux
> kernel into the mainline kernel. I actually gave up, because it
> seemed utterly pointless, even though it was clearly a design error
> that I was fixing, and I was trying to meet all the constraints on
> patches. No one was fighting me, no one said it was wrong.

It sounds like the real problem is no one was paying attention to you.
There is a *huge* number of changes going into the Linux kernel, and
so the the challenge is getting review bandwidth by the relevant
maintainers.  Blindly posting to the linux-kernel mailing list will
generally not get you very far.

The Linux development process is not really optimized for "drive by
patching".  Knowng where (and to whom) a patch needs to be reviewed is
not necessarily easy for a novice, and while there are tools such as
./scripts/get_maintainer.pl that try to make it a bit easier, I can
see how someone who Just Wants To Get A Single Patch accepted, can see
it as "bureaucracy".

Cheers,

					- Ted