From: Neil Horman <nhorman@tuxdriver.com>
To: Thomas Monjalon <thomas.monjalon@6wind.com>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH 0/4] Add DSO symbol versioning to support backwards compatibility
Date: Fri, 26 Sep 2014 10:45:49 -0400 [thread overview]
Message-ID: <20140926144549.GA5619@hmsreliant.think-freely.org> (raw)
In-Reply-To: <1449997.vdXo3dW1jx@xps13>
On Fri, Sep 26, 2014 at 12:41:33PM +0200, Thomas Monjalon wrote:
> Hi Neil,
>
> 2014-09-24 14:19, Neil Horman:
> > Ping Thomas. I know you're busy, but I would like this to not fall off anyones
> > radar. You alluded to concerns regarding what, for lack of a better term,
> > ABI/API lockin. I had asked you to enuumerate/elaborate on specifics, but never
> > heard back. Are there further specifics you wish to discuss, or are you
> > satisfied with the above answers?
>
> Sorry for not being very reactive on this thread.
> All this discussion is very interesting but it's really not the proper
> time to apply it. As you said, it requires an extra effort. I'm not saying
> it will never be integrated. I'm just saying that we cannot change
> everything at the same time.
>
> Let me sum up the situation. This community project has been very active
> for few months now. First, we learnt how to make some releases together
> and we are improving the process to be able to deliver a new major release
> every 4 months while having some good quality process.
> But these releases are still not complete because documentation is not
> integrated yet. Then developers should have a role in documentation updates.
> We also need to integrate and learn how to use more tools to be more
> efficient and improve quality.
>
> So the question is "when should we care about API compatibility"?
> And the answer is: ASAP, but not now. I feel next year is a better target.
> Because the most important priority is to move together at a pace which
> allow most of us to stay in the race.
>
I'm sorry Thomas, I don't accept this. I asked you for details as to your
concerns regarding this patch series, and you've provided more vague comments.
I need details to address
You say it requires extra effort, you're right it does. Any feature that you
integreate requires some additional effort. How is this patch any different
from adding the acl library or any other new API? Everything requires
maintenence, thats how software works. What specfically about this patch series
makes the effort insurmountable to you?
You say you're improving your process. Great, this patch aids in that process
by ensuring backwards compatibility for a period of time. Given that the API
and ABI can still evolve within this framework, as I've described, how is this
patch series not a significant step forward toward your goal of quality process.
You say documentation isn't integrated. So, what does getting documentation
integrated have to do with this patch set, or any other? I don't see you
holding any other patches based on documentation. Again, nothing in this series
prevents evolution of the API or ABI. If you're hope is to wait until
everything is perfect, then apply some control to the public facing API, and get
it all documented, none of thosse things will ever happen, I promise you.
You say you also need to learn to use more tools to be more efficient and
improve quality. Great! Thats exactly what this is. If we mandate even a short
term commitment to ABI stability (1 single relese worth of time), we will
quickly identify what API's change quickly and where we need to be cautious with
our API design. If you just assume that developers will get better of their own
volition, it will never happen.
You say this should go in next year, but not now. When exactly? What event do
you forsee occuring in the next 12-18 months that will change everything such
that we can start supporing an ABI for more than just a few weeks at the head of
the tree?
To this end, I just did a quick search through the git history for dpdk to look
at the histories of all the header files that are exposed via the makefile
SYMLINK command (given that that provides a list of header files that
applications can include, and embodies all the function symbols and data types
applications have access to.
There are 179 total commits in that list
Of those, a bit of spot checking suggests that about 10-15% of them actually
change ABI, and many of those came from Bruce's rework of the mbuf structure.
That about 17-20 instances over the last 2 years where an ABI update would have
been needed. That seems pretty reasonable to me. Where exactly is your concern
here?
Neil
> --
> Thomas
>
next prev parent reply other threads:[~2014-09-26 14:39 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-15 19:23 Neil Horman
2014-09-15 19:23 ` [dpdk-dev] [PATCH 1/4] compat: Add infrastructure to support symbol versioning Neil Horman
2014-09-23 10:39 ` Sergio Gonzalez Monroy
2014-09-23 14:58 ` Neil Horman
2014-09-23 16:29 ` Sergio Gonzalez Monroy
2014-09-23 17:31 ` Neil Horman
2014-09-25 18:52 ` [dpdk-dev] [PATCH 1/4 v2] " Neil Horman
2014-09-26 14:16 ` Sergio Gonzalez Monroy
2014-09-26 15:16 ` Neil Horman
2014-09-26 15:33 ` Sergio Gonzalez Monroy
2014-09-26 16:22 ` Neil Horman
2014-09-26 19:19 ` Neil Horman
2014-09-29 15:44 ` [dpdk-dev] [PATCH 1/4 v3] " Neil Horman
2014-09-30 8:13 ` Sergio Gonzalez Monroy
2014-09-30 15:18 ` [dpdk-dev] [PATCH 1/4 v4] " Neil Horman
2014-10-01 10:15 ` Sergio Gonzalez Monroy
2014-10-01 10:38 ` Neil Horman
2014-10-01 11:28 ` Sergio Gonzalez Monroy
2014-09-15 19:23 ` [dpdk-dev] [PATCH 2/4] Provide initial versioning for all DPDK libraries Neil Horman
2014-09-19 9:45 ` Bruce Richardson
2014-09-19 10:22 ` Neil Horman
2014-10-01 11:25 ` Sergio Gonzalez Monroy
2014-10-01 14:43 ` Neil Horman
2014-09-15 19:23 ` [dpdk-dev] [PATCH 3/4] Add library version extenstion Neil Horman
2014-10-01 11:27 ` Sergio Gonzalez Monroy
2014-09-15 19:23 ` [dpdk-dev] [PATCH 4/4] docs: Add ABI documentation Neil Horman
2014-10-01 16:06 ` Sergio Gonzalez Monroy
2014-09-18 18:23 ` [dpdk-dev] [PATCH 0/4] Add DSO symbol versioning to support backwards compatibility Thomas Monjalon
2014-09-18 19:14 ` Neil Horman
2014-09-19 8:57 ` Richardson, Bruce
2014-09-19 14:18 ` Venkatesan, Venky
2014-09-19 17:45 ` Neil Horman
2014-09-24 18:19 ` Neil Horman
2014-09-26 10:41 ` Thomas Monjalon
2014-09-26 14:45 ` Neil Horman [this message]
2014-09-26 22:02 ` Stephen Hemminger
2014-09-27 2:22 ` Neil Horman
2014-10-01 18:59 ` Neil Horman
2014-10-07 21:01 ` Neil Horman
2014-10-08 15:57 ` Thomas Monjalon
2014-10-08 18:46 ` Butler, Siobhan A
2014-10-08 19:09 ` Neil Horman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140926144549.GA5619@hmsreliant.think-freely.org \
--to=nhorman@tuxdriver.com \
--cc=dev@dpdk.org \
--cc=thomas.monjalon@6wind.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).