Hi all, 2014-08-08 10:30, Neil Horman: > On Fri, Aug 08, 2014 at 01:09:34PM +0000, Ananyev, Konstantin wrote:
> > > > Also I think user should have an ability to change default classify > > > > code path without modifying/rebuilding acl library. > > > I agree, but both the methods we are advocating for allow that. Its > > > really just > > > a question of exposing the mechanism as data or text in the binary. > > > Exposing it > > > as data comes with implicit ABI constraints that are less prevalanet when > > > done > > > as code entry points. > > > > > > For example: a bug in an optimised code path is discovered, or user may > > > > want to implement and use his own version of classify(). > > > Of course, he probably will report about it and we probably fix it sooner > > or later. > > But with such ability he can switch to the safe implementation immediately > > without touching the library and then wait for the fix. > > Thats not how users of a binary pacakge from a distribution operate. If their > using a binary package they either: > > 1) Don't want to rebuild anything themselves, in which case they file the bug, > and wait for the developers to fix the issue. > > or > > 2) Have a staff to help them work around the issue, which will be done by > rebuilding/fixing the library, not the application. > > With (2), what I am saying is that, if a 3rd party finds a bug in the > classifier > code within dpdk which is built as a shared library within a distribution, and > they need it fixed immediately, they have a choice of what to do, they can > either (a), write a custom classifier function and point the dpdk library to > it, > or (b), just fix the bug in the library directly. Given that, if they can > accomplish (a), they by all rights can also accompilsh (b), the only decision > they need to make is one which makes the most sense for them. The answer is > (b), because thats where the functionality lives. i.e. when the fix occurs > upstream and a new release gets issued, you can go back to using the library > maintained version, and you don't have to clean up what has become vestigial > unused code. I think it's even simpler: thinking API to allow behaviour changes without rebuilding is not sane. So we should expose all functions? Please try to reduce API as much as possible. Thanks -- Thomas
