[dpdk-dev] [PATCH 02/20] ethdev: allow drivers to return error on close

Stephen Hemminger stephen at networkplumber.org
Thu Sep 24 16:48:30 CEST 2020


On Thu, 24 Sep 2020 10:12:46 +0100
Bruce Richardson <bruce.richardson at intel.com> wrote:

> On Thu, Sep 24, 2020 at 12:35:58AM +0200, Thomas Monjalon wrote:
> > 24/09/2020 00:02, Stephen Hemminger:  
> > > On Wed, 23 Sep 2020 23:52:07 +0200
> > > Thomas Monjalon <thomas at monjalon.net> wrote:
> > >   
> > > > > > > > Yes it is a step in the right direction.
> > > > > > > > Changing the API means adding some error checks in every apps.
> > > > > > > > The reason for not doing is that I did not commit for this task,
> > > > > > > > and I am not the author of the deprecation notice.
> > > > > > > > We can discuss how to follow up once this series is merged.      
> > > > > > > 
> > > > > > > Not sure what application can really do if dev_close fails other than call rte_exit()?      
> > > > > > 
> > > > > > At least, it can show a message to the user.    
> > > > > 
> > > > > Agree, but no code checks return from close() system call now.
> > > > > At least testpmd should be updated; the examples are fine.    
> > > > 
> > > > How do you explicitly silence the static code analyzers?
> > > > Do you recommend adding (void) in front of the call to close()?  
> > > 
> > > Coverity usually gives something like, "return value of foo() is not checked
> > > but checked 10 other places"  
> > 
> > Yes so it should be silenced with (void) or ret =
> >   
> Does coverity still give the warning if the majority of cases don't
> actually check the return value?

It looks like coverity only looks at some functions and if majority is checking.
For example, it never nags about just calling close().


More information about the dev mailing list