20/03/2018 23:42, Arnon Warshavsky: > > Thanks for working on this important topic. > > With pleasure :) > > > My feeling is that we could replace most of them by a log + return. > > I did not think you would add a new macro. Why you chose this way? > > This was meant to keep the code shorter, and imply to the reader that this > return is actually meant to be fatal > > > > > I would like to define a device health state that can be monitored from > > > the side,and this will be an independant patch. > > > > You mean when a device become unusable? > > Yes. Obviously not a simple issue, but essential for refraining from panic > in the interrupt/data-path context, > while allowing to detect and execute on the slow/management path. > > > > - Some previously panicing void functions where changed to return a > > > value, with callers modified accordingly. > > > > If the function is exposed to the application, I think it is an ABI change > > and should follow the deprecation process. > > In this case I thought there would be no actual change for the user as the > transition is from returning void to int, > and existing calls should continue to behave as before (except for not > crashing)
You are talking about API, and I agree the old applications can keep considering the functions as void. But I was talking about ABI, meaning: can we use an old application without recompiling and update only the DPDK (in .so file)?
