Slashdot Mirror
Linus Torvalds No Longer Knows the Whole Linux Kernel and That's OK (eweek.com)
darthcamaro writes: In a wide-ranging conversation at the Open Source Summit, Linus Torvalds admitted that he no longer knows everything that's in LInux. "Nobody knows the whole kernel anymore," Torvalds said. "Having looked at patches for many years, I know the big picture of all the areas in the kernel and I can look at a patch and know if it's right or wrong." Overall, he emphasized that being open source has enabled Linux to attract new developers that can pick up code and maintain all the various systems in Linux. In his view, the only way to deal with complexity is to be open. "When you have complexity you can't manage it in a closed environment, you need to have the people that actually find problems and give them the ability to get involved and help you to fix them," Torvalds said. "It's a complicated world and the only way to deal with complexity is the open exchange of ideas."
"Performance is not really doubling every two years and that's good," Torvalds said. "It means we'll maybe go back to the time when you cared more about performance on the software side and you had to be more careful and couldn't just rely on hardware getting better."
He's wrong: it means we'll just get slower and slower software because hardly anyone knows how to do anything besides paste libraries together.
"First they came for the slanderers and i said nothing."
There is something in-between.
... I'm not talking about a few years after stabilizing, I'm talking as soon as the monster code base called the kernel no longer depends on them. Forget that there are external modules build from DKMS other other tools that need to handle different versions. And we're not talking about massive APIs, we're talking about things that support name changes.
I love microkernels and have written a few for personal entertainment. I have even been following Fuschia OS's development quite closely... though I can't believe anyone would make something that shitty from the ground up in 2018.
A more or less monolithic with a pluggable and stable ABI and API is often the best of both worlds. Add some form of module signing and code review process and we're in a good place.
After all these years, there has been ample opportunity to optimize microprocessor design to make a better microkernel CPU. There is generally just too much cost involved in the constant context swaps for a desktop OS. Remember that we spent many years trying to trim the fat between application and graphics subsystems. Even today, it's pretty simply to almost devastate the performance of a micro kernel with a massive amount of disk I/O operations.
Last month, I wrote a new Linux kernel module. I needed to implement the Cisco Discovery Protocol on Linux in a less stupid way than it's been done until now. I believe I achieved doing it equally dumb from an opposite direction. This is because the Linux Kernel is an enormous disaster of crap on crap.
Let's talk about something relatively simple that should have been ripped out and entirely moved out of the kernel a LONG time ago... the network stack.
The Linux network stack is amazingly fast and should be given credit for being that way.
It's also a cesspool of shit code from almost end to end. Probably the most important piece of code in the Linux kernel is sk_buff. Oh... sk_buff, you are the biggest, ugliest and shittiest piece of code in the entire world. I mean... you're a buffer... a kinda sorta reference counted buffer which never really gets deleted...except when you do. You're a huge chunk of trash code that looks like you were designed by a drug fuddled preschooler that wanted to try daddy's C compiler while on a series trip.
sk_buff is probably the most critical piece of code to keep the documentation up to date on. This is the code which makes things like kernel panics in the weirdest ways when even the slightest thing goes wrong. And yet, after 27 years of Linux, you guys still can't seem to stabilize the API for the frigging network buffer!!!
Then let's consider procfs...
So... procfs is basically the ability for a user mode application to access a file and it calls procedures for reads and writes... well all files in the kernel work that way, but procfs is a bit special, it was meant to be informative and work in a printf'ish kinda way.
procfs for the most part is nothing more than, open, read, write, seek, close. It doesn't need anything other than that. It's a simple random access file stream.
Somehow, the API is still changing like mad... and worse the transition mechanisms that support the newer APIs are actually getting removed from the kernel
I was looking into adding a new address family to the kernel for CDP... and I tried looking at other code for a good example. I absolutely refuse to make pull requests to the Linux kernel unless it's a bug fix (and deleting the whole tree and starting over doesn't count). I believe that tools like DKMS should point to git repositories and download drivers and build them against the kernel. CDP does not need to be part of the mainstream kernel. It's a tool.
Well, as I said, I was looking into it. And after this many years, because of the absolute shitty state of the kernel... I'd at least have to register AF_CDP and PF_CDP somewhere so that I could have my very own protocol number. And for the most part, that would prob