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

Hi all,

2014-08-08 10:30, Neil Horman:

On Fri, Aug 08, 2014 at 01:09:34PM +0000, Ananyev, Konstantin wrote:

quoted

quoted

quoted

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.

quoted

quoted

For example: a bug in an optimised code path is discovered, or user may want to implement and use his own version of classify().

quoted

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