From: Thomas Monjalon <thomas.monjalon@6wind.com>
To: Panu Matilainen <pmatilai@redhat.com>
Cc: dev@dpdk.org
Subject: Re: [PATCH] cryptodev: mark experimental state
Date: Fri, 27 Nov 2015 14:30:02 +0100 [thread overview]
Message-ID: <7197986.Uky0E0JuXH@xps13> (raw)
In-Reply-To: <56585604.9030909@redhat.com>
2015-11-27 15:09, Panu Matilainen:
> On 11/26/2015 03:51 PM, Doherty, Declan wrote:
> > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> >> 2015-11-26 10:00, Panu Matilainen:
> >>> On 11/26/2015 09:39 AM, Panu Matilainen wrote:
> >>>> I think an experimental library which declares itself exempt from the
> >>>> ABI policy should not be compiled by default. That way anybody wanting
> >>>> to try it out will be forced to notice the experimental status.
> >>>>
> >>>> More generally / longer term, perhaps there should be a
> >>>> CONFIG_RTE_EXPERIMENTAL which wraps all experimental features and
> >>>> defaults to off.
> >>>
> >>> On a related note, librte_mbuf_offload cannot be built if
> >>> CONFIG_RTE_LIBRTE_CRYPTODEV is disabled. Which seems to suggest its (at
> >>> least currently) so tightly couple to cryptodev that perhaps it too
> >>> should be marked experimental and default to off.
> >>
> >> I think you are right.
> >> Declan, what is your opinion?
> >
> >
> > Hey Thomas, yes librte_mbuf_offload should also be set as experimental, it's
> > probably one of the areas which will most likely change in the future.
> >
> > On the issue of turning off experimental libraries in the build by default, my
> > preference would be not to turn them off unless the library has external
> > dependencies, otherwise the possibility of patches being submitted which
> > could break an experimental library will be much higher. In my opinion the
> > fewer build configurations developers have to test against the better.
>
> What I'm more worried about is users and developers starting to rely on
> it while still in experimental state, a single comment in the header is
> really easy to miss.
There are some comments in the config, the header file, doxygen and the release notes.
When using a feature, you have to read the header or the doc.
So would it be better advertised by adding a comment in the doxygen section of
some of the mandatory functions or structures?
> So I'd like to see *some* mechanism which forces users and developers to
> acknowledge the fact that they're dealing with experimental work.
> Defaulting to off is one possibility, another one would be wrapping
> experimental APIs behind a define which you have to set to be able to
> use the API, eg:
>
> #if defined(I_KNOW_THIS_IS_EXPERIMENTAL_AND_MAY_EAT_BABIES)
> [...]
> #endif
Are you sure about the babies? ;)
next prev parent reply other threads:[~2015-11-27 13:31 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-25 17:38 [PATCH] cryptodev: mark experimental state Thomas Monjalon
2015-11-25 20:59 ` Thomas Monjalon
2015-11-26 7:39 ` Panu Matilainen
2015-11-26 8:00 ` Panu Matilainen
2015-11-26 10:08 ` Thomas Monjalon
2015-11-26 13:51 ` Doherty, Declan
2015-11-27 13:09 ` Panu Matilainen
2015-11-27 13:30 ` Thomas Monjalon [this message]
2015-12-11 23:34 ` [PATCH] mbuf_offload: " Thomas Monjalon
2015-12-11 23:44 ` Thomas Monjalon
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=7197986.Uky0E0JuXH@xps13 \
--to=thomas.monjalon@6wind.com \
--cc=dev@dpdk.org \
--cc=pmatilai@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.