DPDK patches and discussions
 help / color / mirror / Atom feed
From: Bruce Richardson <bruce.richardson@intel.com>
To: Ferruh Yigit <ferruh.yigit@amd.com>
Cc: <dev@dpdk.org>
Subject: Re: [PATCH v2] app/testpmd: show output of commands read from file
Date: Thu, 22 Aug 2024 18:18:50 +0100	[thread overview]
Message-ID: <Zsdy-gzSBuH9uX89@bricha3-mobl1.ger.corp.intel.com> (raw)
In-Reply-To: <ZsdyD_Ln1p6JOgUy@bricha3-mobl1.ger.corp.intel.com>

On Thu, Aug 22, 2024 at 06:14:55PM +0100, Bruce Richardson wrote:
> On Thu, Aug 22, 2024 at 05:53:27PM +0100, Ferruh Yigit wrote:
> > On 8/22/2024 11:41 AM, Bruce Richardson wrote:
> > > Testpmd supports the "--cmdline-file" parameter to read a set of initial
> > > commands from a file. However, the only indication that this has been
> > > done successfully on startup is a single-line message, no output from
> > > the commands is seen.
> > > 
> > 
> > For user I think it makes sense to see the command [1], only concern is
> > if someone parsing testpmd output may be impacted on this, although I
> > expect it should be trivial to update the relevant parsing.
> > 
> > [1]
> > Btw, I can still see the command output, I assume because command does
> > the printf itself, for example for 'show port summary 0' command:
> > - before patch:
> > ...
> > Number of available ports: 2
> > Port MAC Address       Name         Driver         Status   Link
> > 0    xx:xx:xx:xx:xx:xx xxxx:xx:xx.x aaaaaaaa       up       xxx Gbps
> > ...
> > 
> > - after patch
> > ...
> > testpmd> show port summary 0
> > Number of available ports: 2
> > Port MAC Address       Name         Driver         Status   Link
> > 0    xx:xx:xx:xx:xx:xx xxxx:xx:xx.x aaaaaaaa       up       xxx Gbps
> > ...
> > 
> > Only difference above is, after patch the command itself also printed.
> > 
> > 
> 
> That's because the function uses printf itself, which is actually wrong.
> Any output from a cmdline function should use the "cmdline_printf" call
> which outputs to the proper cmdline filehandle.
> 
> > > To improve usability here, we can use cmdline_new rather than
> > > cmdline_file_new and have the output from the various commands sent to
> > > stdout, allowing the user to see better what is happening.
> > > 
> > > Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> > > 
> > > ---
> > > v2: use STDOUT_FILENO in place of hard-coded "1"
> > > ---
> > >  app/test-pmd/cmdline.c | 14 +++++++++++++-
> > >  1 file changed, 13 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
> > > index b7759e38a8..52e64430d9 100644
> > > --- a/app/test-pmd/cmdline.c
> > > +++ b/app/test-pmd/cmdline.c
> > > @@ -6,6 +6,7 @@
> > >  #include <ctype.h>
> > >  #include <stdarg.h>
> > >  #include <errno.h>
> > > +#include <fcntl.h>
> > >  #include <stdio.h>
> > >  #include <stdint.h>
> > >  #include <stdlib.h>
> > > @@ -13431,7 +13432,18 @@ cmdline_read_from_file(const char *filename)
> > >  {
> > >  	struct cmdline *cl;
> > >  
> > > -	cl = cmdline_file_new(main_ctx, "testpmd> ", filename);
> > > +	/* cmdline_file_new does not produce any output which is not ideal here.
> > > +	 * Much better to show output of the commands, so we open filename directly
> > > +	 * and then pass that to cmdline_new with stdout as the output path.
> > > +	 */
> > > +	int fd = open(filename, O_RDONLY);
> > > +	if (fd < 0) {
> > > +		fprintf(stderr, "Failed to open file %s: %s\n",
> > > +			filename, strerror(errno));
> > > +		return;
> > > +	}
> > > +
> > > +	cl = cmdline_new(main_ctx, "testpmd> ", fd, STDOUT_FILENO);
> > >
> > 
> > Above is almost save as 'cmdline_file_new()' function with only
> > difference that it uses '-1' for 's_out'.
> > 
> > If this usecase may be required by others, do you think does it have a
> > value to pass 's_out' to 'cmdline_file_new()' or have a new version of
> > API that accepts 's_out' as parameter?
> > 
> 
> Yes, I thought about this, and actually started implementing a new API for
> cmdline library to that. However, I decided that, given the complexity
> here, that it's not really necessary - especially as there is no clear way
> to do things. The options are:
> 
> * extend cmdline_file_new to have a flag to echo to stdout (which would be
>   the very common case here).
> * extend cmdline_file_new to take a file handle - this is more flexible,
>   but slightly less usable.
> * add a new cmdline_file_<something>_new function to echo to stdout.
> * add a new cmdline_file_<something>_new function to write to a filehandle.
> 
> I don't like breaking the cmdline API (and ABI), so I didn't want to do
> either #1 or #2, which would be the cleanest solutions. For #3 and #4,
> naming is hard, and deciding between them is even harder. Given the choice,
> I prefer #3, as I can't see #4 being very common and we always have
> cmdline_new as a fallback anyway.
> 
> Overall, though, I threw away that work, because it didn't seem worth it,
> for the sake of having the user to do an extra "open" call.
> 

And also to add:
If there is clear consensus on what the correct option for this case is,
I'm happy enough to go back and extend the cmdline library as agreed.
:-)

  reply	other threads:[~2024-08-22 17:19 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-22 10:36 [PATCH] " Bruce Richardson
2024-08-22 10:41 ` [PATCH v2] " Bruce Richardson
2024-08-22 16:53   ` Ferruh Yigit
2024-08-22 17:14     ` Bruce Richardson
2024-08-22 17:18       ` Bruce Richardson [this message]
2024-08-22 21:09         ` Ferruh Yigit
2024-08-23  9:12           ` Bruce Richardson
2024-10-04  4:56   ` Ferruh Yigit
2024-10-08  1:33     ` Ferruh Yigit
2024-10-10  8:56       ` David Marchand
2024-10-10  9:46         ` Bruce Richardson
2024-10-04  4:55 ` [PATCH] " Ferruh Yigit
2024-10-04  4:56   ` Ferruh Yigit

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=Zsdy-gzSBuH9uX89@bricha3-mobl1.ger.corp.intel.com \
    --to=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@amd.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;
as well as URLs for NNTP newsgroup(s).