All of lore.kernel.org
 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 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.