From mboxrd@z Thu Jan 1 00:00:00 1970 From: Don Slutz Subject: Re: [PATCH v5 04/17] xenctx: Add command line options -b (--bytes-per-line) and -l (--lines) Date: Mon, 24 Mar 2014 12:58:24 -0400 Message-ID: <53306430.5070605@terremark.com> References: <1395342425-16260-1-git-send-email-dslutz@verizon.com> <1395342425-16260-5-git-send-email-dslutz@verizon.com> <1395412371.19839.108.camel@kazak.uk.xensource.com> <532DEDC5.6020802@terremark.com> <1395657858.19365.35.camel@kazak.uk.xensource.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6927358371552305953==" Return-path: In-Reply-To: <1395657858.19365.35.camel@kazak.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell , Don Slutz Cc: George Dunlap , Stefano Stabellini , Ian Jackson , Jan Beulich , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org This is a multi-part message in MIME format. --===============6927358371552305953== Content-Type: multipart/alternative; boundary="------------060303050303030509000205" This is a multi-part message in MIME format. --------------060303050303030509000205 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 03/24/14 06:44, Ian Campbell wrote: > On Sat, 2014-03-22 at 16:08 -0400, Don Slutz wrote: >> On 03/21/14 10:32, Ian Campbell wrote: >> By default only part of the stack is dumped: > Why not dump the whole page by default then? 5 lines seems rather > arbitrary. 5 is what it use to be. Not sure how much the default in linux is. I have no issue with changing the default to MAX. However I got from reading Jan Beulich comments in Nov 2013, that these changes should not be intrusive. >> "less", "head" or "tail" are unable to change xenctx, only control >> what you see of xenctx's output. > Obviously! I'm not sure what your point is though -- my suggestion was > that xenctx should/could output stuff which can be processed with these > tools. Looks like I misunderstood you. >> It is not that each change makes a big difference, that happens when >> several are used at one time: > Can we not just improve the default behaviour to be more useful? Having > to give half a dozen different options to get useful output isn't really > all that user friendly. These are directly in response to: -------- Original Message -------- Subject: Re: [PATCH v2 04/12] xenctx: Add stack address to dump, switch to 16 bytes per line. Date: Thu, 7 Nov 2013 08:12:44 +0000 From: Jan Beulich To: Don Slutz CC: Ian Campbell , Don Slutz , George Dunlap , Ian Jackson , Stefano Stabellini , xen-devel >>> On 06.11.13 at 21:08, Don Slutz wrote: Again - why? This makes it just two entries per line for a 64-bit guest. Pretty little I would say. Jan > I accept that some options might have to remain in order to work sanely > on 80-column displays but we should aim in the first instance to have > the tool Do The Right/Useful Thing without needing extra options. I am currently not sure that "Do The Right/Useful Thing" is the same for all the people involved. Are you asking for some kind of config file that allows a developer to select their preferred setting of options, or just to determine the best defaults? Last I knew Jan Beulich does not what -t and you and I do. The issue is that -t by default pushes the output to > 80 columns. -Don Slutz > Ian. > --------------060303050303030509000205 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 03/24/14 06:44, Ian Campbell wrote:
On Sat, 2014-03-22 at 16:08 -0400, Don Slutz wrote:
On 03/21/14 10:32, Ian Campbell wrote:
By default only part of the stack is dumped:
Why not dump the whole page by default then? 5 lines seems rather
arbitrary.

5 is what it use to be.  Not sure how much the default in linux is.

I have no issue with changing the default to MAX.  However I got
from reading Jan Beulich comments in Nov 2013, that these changes
should not be intrusive.


      
"less", "head" or "tail" are unable to change xenctx, only control
what you see of xenctx's output.
Obviously! I'm not sure what your point is though -- my suggestion was
that xenctx should/could output stuff which can be processed with these
tools.

Looks like I misunderstood you.


      
It is not that each change makes a big difference, that happens when 
several are used at one time:
Can we not just improve the default behaviour to be more useful? Having
to give half a dozen different options to get useful output isn't really
all that user friendly.

These are directly in response to:

-------- Original Message --------
Subject: Re: [PATCH v2 04/12] xenctx: Add stack address to dump, switch to 16 bytes per line.
Date: Thu, 7 Nov 2013 08:12:44 +0000
From: Jan Beulich <JBeulich@suse.com>
To: Don Slutz <dslutz@verizon.com>
CC: Ian Campbell <ian.campbell@citrix.com>, Don Slutz <Don@CloudSwitch.com>, George Dunlap <george.dunlap@eu.citrix.com>, Ian Jackson <ian.jackson@eu.citrix.com>, Stefano Stabellini <stefano.stabellini@eu.citrix.com>, xen-devel <xen-devel@lists.xenproject.org>


>>> On 06.11.13 at 21:08, Don Slutz <dslutz@verizon.com> wrote:

Again - why? This makes it just two entries per line for a 64-bit
guest. Pretty little I would say.

Jan



I accept that some options might have to remain in order to work sanely
on 80-column displays but we should aim in the first instance to have
the tool Do The Right/Useful Thing without needing extra options.

I am currently not sure that "Do The Right/Useful Thing" is the same
for all the people involved.

Are you asking for some kind of config file that allows a developer to select
their preferred setting of options, or just to determine the best defaults?

Last I knew Jan Beulich does not what -t and you and I do.  The issue is that
-t by default pushes the output to > 80 columns.

   -Don Slutz

Ian.


--------------060303050303030509000205-- --===============6927358371552305953== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============6927358371552305953==--