All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Monjalon <thomas@monjalon.net>
To: Arnon Warshavsky <arnon@qwilt.com>
Cc: "Burakov, Anatoly" <anatoly.burakov@intel.com>,
	wenzhuo.lu@intel.com, declan.doherty@intel.com,
	jerin.jacob@caviumnetworks.com,
	Bruce Richardson <bruce.richardson@intel.com>,
	ferruh.yigit@intel.com, dev@dpdk.org
Subject: Re: [PATCH] eal: replace rte_panic instances to return an error value
Date: Tue, 20 Mar 2018 23:49:59 +0100	[thread overview]
Message-ID: <1645860.rB6cz0fKiK@xps> (raw)
In-Reply-To: <CAKy9EB2OUyg-kG9bzDB_84okJ4Tn2cpGocU6dmP0njEJ8bWiWA@mail.gmail.com>

20/03/2018 23:42, Arnon Warshavsky:
> > Thanks for working on this important topic.
> 
> With pleasure :)
> 
> > My feeling is that we could replace most of them by a log + return.
> > I did not think you would add a new macro. Why you chose this way?
> 
> This was meant to keep the code shorter, and imply to the reader that this
> return is actually meant to be fatal
> >
> > >   I would like to define a device health state that can be monitored from
> > >   the side,and this will be an independant patch.
> >
> > You mean when a device become unusable?
> 
> Yes. Obviously not a simple issue, but essential for refraining from panic
> in the interrupt/data-path context,
> while allowing to detect and execute on the slow/management path.
> 
> > > - Some previously panicing void functions where changed to return a
> > > value, with callers modified accordingly.
> >
> > If the function is exposed to the application, I think it is an ABI change
> > and should follow the deprecation process.
> 
> In this case I thought there would be no actual change for the user as the
> transition is from returning void to int,
> and existing calls should continue to behave as before (except for not
> crashing)

You are talking about API, and I agree the old applications can keep
considering the functions as void.
But I was talking about ABI, meaning: can we use an old application
without recompiling and update only the DPDK (in .so file)?

  reply	other threads:[~2018-03-20 22:50 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-20 21:28 [PATCH] eal: replace rte_panic instances to return an error value Arnon Warshavsky
2018-03-20 22:04 ` Thomas Monjalon
2018-03-20 22:42   ` Arnon Warshavsky
2018-03-20 22:49     ` Thomas Monjalon [this message]
2018-03-20 23:04       ` Arnon Warshavsky
2018-03-21  8:21         ` Thomas Monjalon
2018-03-21  8:47           ` Arnon Warshavsky

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=1645860.rB6cz0fKiK@xps \
    --to=thomas@monjalon.net \
    --cc=anatoly.burakov@intel.com \
    --cc=arnon@qwilt.com \
    --cc=bruce.richardson@intel.com \
    --cc=declan.doherty@intel.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=jerin.jacob@caviumnetworks.com \
    --cc=wenzhuo.lu@intel.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.