Re: [dpdk-dev] [PATCHv2] librte_acl make it build/work for 'default' target

[Thomas Monjalon <thomas.monjalon@6wind.com>]

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