From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id D7EC13B2A4; Mon, 29 Mar 2021 21:52:47 -0400 (EDT) Received: from cwcc.thunk.org (pool-72-74-133-215.bstnma.fios.verizon.net [72.74.133.215]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 12U1qitj005341 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 29 Mar 2021 21:52:45 -0400 Received: by cwcc.thunk.org (Postfix, from userid 15806) id 92C9D15C39CD; Mon, 29 Mar 2021 21:52:44 -0400 (EDT) Date: Mon, 29 Mar 2021 21:52:44 -0400 From: "Theodore Ts'o" To: "David P. Reed" Cc: Dave Taht , Cake List , Make-Wifi-fast , "Jason A. Donenfeld" , cerowrt-devel , bloat Message-ID: References: <1617049691.187521510@apps.rackspace.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1617049691.187521510@apps.rackspace.com> X-Mailman-Approved-At: Tue, 30 Mar 2021 12:25:34 -0400 Subject: Re: [Bloat] [Cerowrt-devel] wireguard almost takes a bullet X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2021 01:52:48 -0000 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