Re:Building a faster, smarter, Chromebook experience with th...
by vetinari on Thursday June 13, 2024 @04:21AM
(#40667215)
That someone updating the drivers is exactly the same person who makes the change in the subsystem that they depend on. They cannot break what is already in the kernel, but they can break what's outside; it is after all an internal API.
Re:Building a faster, smarter, Chromebook experience with th...
by codedokode on Thursday June 13, 2024 @06:18AM
(#40667854)
And that is wrong because people might have reason not to mainline drivers.
Re:Building a faster, smarter, Chromebook experience with th...
by vetinari on Thursday June 13, 2024 @06:55AM
(#40668057)
That's fine; but their reason is their problem. They are not entitled to free labor of other people.
Re:Building a faster, smarter, Chromebook experience with th...
by pantalaimon on Thursday June 13, 2024 @08:23AM
(#40668771)
What reasons are there other that corporate shenanigans?
Sure it takes more effort to mainline the driver and address review comments, but if you aren't designing a throw-away product, it's effort well spent.
Re:Building a faster, smarter, Chromebook experience with th...
by account42 on Thursday June 13, 2024 @09:10AM
(#40669213)
Those reasons tend to be petty ones that benefit the hardware company and noone else. Seems fair that the hardware company should pay for the consequences of their decisions and not the people advancing the kernel.
You don't, but someone does. In the note linked above they give an example of how the USB interface changed from synchronous to asynchronous, this must have required some refactoring in all drivers that used USB