On Fri, 1 Dec 2023 12:55:52 +0100 Michal Hocko <mhocko@xxxxxxxx> wrote: > On Fri 01-12-23 12:33:53, Philipp Rudo wrote: > [...] > > And yes, those are all what-if concerns but unfortunately that is all > > we have right now. > > Should theoretical concerns without an actual evidence (e.g. multiple > drivers known to be broken) become a roadblock for this otherwise useful > feature? Those concerns aren't just theoretical. They are experiences we have from a related feature that suffers exactly the same problem regularly which wouldn't exist if everybody would simply work "properly". And yes, even purely theoretical concerns can become a roadblock for a feature when the cost of those theoretical concerns exceed the benefit of the feature. The thing is that bugs will be reported against kexec. So _we_ need to figure out which of the shitty drivers caused the problem. That puts additional burden on _us_. What we are trying to evaluate at the moment is if the benefit outweighs the extra burden with the information we have at the moment. > > Only alternative would be to run extended tests in > > the field. Which means this user facing change needs to be included. > > Which also means that we are stuck with it as once a user facing change > > is in it's extremely hard to get rid of it again... > > I am not really sure I follow you here. Are you suggesting once > crashkernel=cma is added it would become a user api and therefore > impossible to get rid of? Yes, sort of. I wouldn't rank a command line parameter as user api. So we still can get rid of it. But there will be long discussions I'd like to avoid if possible. Thanks Philipp _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
