Originally posted by coder
View Post
Originally posted by coder
View Post
Originally posted by coder
View Post
Those with a stake in Linux kernel future to take this serous-ally because its important that the kernel can change as hardware evolves this requires drivers to be able to change. If ABI on drivers means kernel space cannot change to match current day hardware it comes trouble very quickly.
Originally posted by coder
View Post
My read on history could be wrong. But if google with their ABI stability plan has not read the history of the other that have done it the will not put in the required counters to adverse effects.
Like one counter would be if you wish to use the google stable ABI for Linux you must also release the source code of that driver so it can be updated by someone else latter if the ABI ever has to change.
Kernel ABI stablity + closed source driver hinders development really quickly. Remember libhybris and android user-space graphics drivers. This is not the first time google has created a stable driver ABI either prior ones were userspace with android. These closed source userspace drivers did end up coming a performance and security bottleneck.
So google kernel driver ABI thing is also like kdbus as a solution to dbus-daemon problems that Linus said was a really bad idea.
coder this is Google second attempt at doing a driver ABI for Linux. Track record of the prior one was basically a failure too.
I remember nuse what was fuse modified for network devices that shows that userspace drivers can have the same performance as kernel base ones. These userspace driver-space interface also provide example of what happens as kernel space and stable driver ABI move out of alignment with each other design.
Basically there is a lot of information that a stable kernel ABI driver is a bad idea. A lot of people forgot we have the fuse, cuse and nuse history to look at as well on what will happen to performance as the driver ABI and the kernel internal design goes out of alignment.
Comment