[dpdk-dev] Marking symbols as experimental in the headers only
David Marchand
david.marchand at redhat.com
Wed Dec 19 10:12:06 CET 2018
On Tue, Dec 18, 2018 at 1:27 PM David Marchand <david.marchand at redhat.com>
wrote:
>
> On Tue, Dec 18, 2018 at 1:25 PM Neil Horman <nhorman at tuxdriver.com> wrote:
>
>> On Tue, Dec 18, 2018 at 11:41:34AM +0100, David Marchand wrote:
>>
>> > The real issue in the end is that the __rte_experimental in headers is
>> the
>> > most important thing and can be missed during reviews.
>> > But I found no easy way to detect this.
>> >
>> > Do you have any idea ?
>> >
>> The most direct way is to add a regular expression search to the script
>> that
>> checks the object files. That would be some tricky grep/awk magic, but it
>> should be possible
>>
>
So, wrote something that I hooked in rte.lib.mk.
On a fresh master branch, I can see:
== Build lib/librte_bbdev
ERROR: rte_bbdev_dequeue_dec_ops is not marked as experimental in this
library headers
ERROR: rte_bbdev_dequeue_enc_ops is not marked as experimental in this
library headers
ERROR: rte_bbdev_devices is not marked as experimental in this library
headers
ERROR: rte_bbdev_enqueue_dec_ops is not marked as experimental in this
library headers
ERROR: rte_bbdev_enqueue_enc_ops is not marked as experimental in this
library headers
ERROR: rte_bbdev_op_pool_create is not marked as experimental in this
library headers
ERROR: rte_bbdev_op_type_str is not marked as experimental in this library
headers
== Build lib/librte_cryptodev
ERROR: rte_crypto_asym_op_strings is not marked as experimental in this
library headers
ERROR: rte_crypto_asym_xform_strings is not marked as experimental in this
library headers
== Build lib/librte_vhost
ERROR: rte_vhost_va_from_guest_pa is not marked as experimental in this
library headers
Those warnings seem valid, need to double check (bbdev is already known).
But my script still needs some work to make it lighter...
A fresh build went from:
real 3m25.823s
user 2m42.026s
sys 1m2.730s
to:
real 3m42.442s
user 2m56.733s
sys 1m5.565s
I think I'd rather adapt it to hook in checkpatches.sh.
Maintainers can then ignore it when the check is broken (my regexp skills
are lacking :)).
--
David Marchand
More information about the dev
mailing list