And then every time there's a vulnerability in the kernel implementation, we need a kernel patch (something that often takes longer to test and release than an update to a userland library) and a reboot. Updating OpenSSL just requires restarting daemons that use it.
At any rate, I don't see why you think that tying TLS to the kernel is required to improve the security posture. OpenSSL can remain a library, and the same companies that fund the Linux kernel can fund OpenSSL. Hell, the people who maintain the existing crypto functionality in the kernel can work on OpenSSL if they so choose.
Then there's the matter of adoption: the main reason that LibreSSL has failed on Linux is because developers don't seem to want to move to it in their applications, despite it having very few differences from OpenSSL. What makes you think developers will adopt a completely different Linux-specific API that doesn't work on any other OS?
At any rate, I don't see why you think that tying TLS to the kernel is required to improve the security posture. OpenSSL can remain a library, and the same companies that fund the Linux kernel can fund OpenSSL. Hell, the people who maintain the existing crypto functionality in the kernel can work on OpenSSL if they so choose.
Then there's the matter of adoption: the main reason that LibreSSL has failed on Linux is because developers don't seem to want to move to it in their applications, despite it having very few differences from OpenSSL. What makes you think developers will adopt a completely different Linux-specific API that doesn't work on any other OS?