Linux DTrace development list
 help / color / mirror / Atom feed
From: Kris Van Hees <kris.van.hees@oracle.com>
To: Eugene Loh <eugene.loh@oracle.com>
Cc: Kris Van Hees <kris.van.hees@oracle.com>,
	dtrace@lists.linux.dev, dtrace-devel@oss.oracle.com
Subject: Re: [PATCH 6/6] procfs: populate pr_argc, pr_argv, and pr_envp with default values
Date: Thu, 30 Jan 2025 19:13:26 -0500	[thread overview]
Message-ID: <Z5wVpqvyvpficImp@oracle.com> (raw)
In-Reply-To: <bde7dcb7-380e-dc11-08bb-58c14a6d5230@oracle.com>

Good point - I'll withdraw the patch.  We can discuss about the best way
to handle the test issues in a later patch (series).

On Thu, Jan 30, 2025 at 06:43:17PM -0500, Eugene Loh wrote:
> On 1/30/25 18:03, Kris Van Hees wrote:
> 
> > On Thu, Jan 30, 2025 at 05:33:45PM -0500, Eugene Loh wrote:
> > > My main question is how it is better to provide incorrect results than it is
> > > not to have implemented this functionality?  How about just waiting until we
> > > implement this functionality?  Isn't it better that a user is told that we
> > > haven't implemented this stuff rather than give them results that are
> > > incorrect?
> > That is always a balance.  Ideally, we should have tests for each independent
> > member of each translator, so that we can do more fine grained testing.  But
> > it is not sensible that we do not end up testing any translator members because
> > some are not implemented, whereas providing a default value for them (which we
> > e.g. also do for members in the io translators).  That is the precedent I am
> > depending on here.
> 
> From the user's point of view, the choice is between:
> 
> *)  the status quo, where an attempt to use one of the unimplemented fields
> returns a rather nice error message that indicates what the problem is
> 
> *)  the proposed patch, where we "silently" return incorrect values, leaving
> the user with incorrect results or wasting time debugging the problem,
> filing a bug, etc.
> 
> So, there is hardly a balance here at all for users:  the status quo is far
> better.
> 
> From our test suite's point of view, there is a choice between less coverage
> (some tests XFAIL) and "more coverage", but I question that characterization
> since the "more coverage" case still doesn't check the correctness of the
> output.  Anyhow, to the extent that this is a test-suite issue, let's fix it
> in the test suite instead of polluting user-visible behavior.  Let's not
> "game the test suite" by modifying dtrace.  The whole set of tst.psinfo*.d
> tests are in need of overhaul;  so let's improve test coverage by cleaning
> up the tests rather than feeding users incorrect results.
> 
> If you'd like me to take a stab at cleaning up tst.psinfo*.d, let me know.
> 
> > > It is odd that XFAIL is being lifted when we are producing incorrect output,
> > > but I suppose that is the burden of some other test/s.  So, okay.
> > Yes, we need more fine grained tests.
> 
> FWIW, test/unittest/builtinvar/tst.psinfo.d would also XPASS with this
> patch.
> 
> > > On 1/28/25 01:31, Kris Van Hees wrote:
> > > > The pr_argc, pr_argv, and pr_envp fields in psinfo are not implemented
> > > > yet, so it makes sense to set them to 0 rather than not providing any
> > > > translator for them.

      reply	other threads:[~2025-01-31  0:13 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-28  6:31 [PATCH 6/6] procfs: populate pr_argc, pr_argv, and pr_envp with default values Kris Van Hees
2025-01-30 22:33 ` Eugene Loh
2025-01-30 23:03   ` Kris Van Hees
2025-01-30 23:43     ` Eugene Loh
2025-01-31  0:13       ` Kris Van Hees [this message]

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=Z5wVpqvyvpficImp@oracle.com \
    --to=kris.van.hees@oracle.com \
    --cc=dtrace-devel@oss.oracle.com \
    --cc=dtrace@lists.linux.dev \
    --cc=eugene.loh@oracle.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