What's the process like for approving and implementing a series of patches this huge in quantity? Seems like it would almost require stalling on other pending issues for a significant amount of time while this is worked in.
It can probably be merged piece by piece, so it won't be a problem.
The reason he wrote the full patch series out like this, is because he wanted to measure the speed gains. Without significant speed gains it would be difficult to convince the kernel developers to make a big uncomfortable change like this.
> The reason he wrote the full patch series out like this, is because he wanted to measure the speed gains.
More importantly, because a lot of the patches involve moving code between files, or making batch changes to a large number of files at once. Evaluating these sorts of changes for correctness is a lot easier when the changes are isolated.
If it does as advertised, probably should not affect too much. Specifically, moving implicit dependencies to explicit should not impact anyone using the dependency. Might trip up code that is adding a new implicit?
> - As to maintenance overhead: it was surprisingly low overhead to keep
dependencies at a minimum across upstream kernel releases - there were
tyically just around ~5 dependency additions that need to be addressed.
This makes me hopeful that an optimal 'fast' state of header
dependencies can be maintained going forward - once the initial set of
fixes are in of course.
The reason he wrote the full patch series out like this, is because he wanted to measure the speed gains. Without significant speed gains it would be difficult to convince the kernel developers to make a big uncomfortable change like this.