From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-f68.google.com (mail-wr1-f68.google.com [209.85.221.68]) by dpdk.org (Postfix) with ESMTP id A7D542965 for ; Wed, 24 Oct 2018 23:46:35 +0200 (CEST) Received: by mail-wr1-f68.google.com with SMTP id d2-v6so7135179wro.7 for ; Wed, 24 Oct 2018 14:46:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WNDi7+wWFqDfu6H/TQbKFz6EQYBrSt8IAkv/J4EbrgA=; b=D+qMrUHeae4lvKZA6fN71suSoq07B3bjJS8Lo3vsTPNGVcQDzEgIUIw4q5l4C2ms27 I7YJ38EhaRh4zaxF7Oo3aNMRxnB+edcmKjTMMBMtVbjTjKeKcKMqh/xGME/FOkDfX7mt Lot3W4Pg8/WQvHWMn52z8bJBKviZUK3L/ISkgeeRs+YLqDnnwZKwn8/m9wlHWFwpaQxN eEE6tHQinFNUvv0Nc01NrXfMDKSQUGAxAeEIeyMsbFvf5XITJmODB74jLzLOVcNlW6yE tVKVKCTbEu2Mromo8OVTqOPE4uoLeFbvIskKEViES7E1tQznYatZtvXNIe2M6wT6MmKx FWyA== X-Gm-Message-State: AGRZ1gJi+e94d7GBtSiw9RZv7dw+15+OjQJLSXf1ebf92t/R5SxCt13f 260kaEHZF0eEm4xYL1f9EuGg0V1WiUG0XIKO4l8= X-Google-Smtp-Source: AJdET5cxQz79Yc989vn+57rQ9T+Gf/rjvz1VjAN1A4V00N4oBnz6rtR6gnC/d30ZQdgVeRvWkzSzZCpRtFAZXsP0o0c= X-Received: by 2002:adf:f2c8:: with SMTP id d8-v6mr1483796wrp.108.1540417595100; Wed, 24 Oct 2018 14:46:35 -0700 (PDT) MIME-Version: 1.0 References: <20180911232906.18352-1-dg@adax.com> <20181024202719.24902-1-dg@adax.com> <20181024202719.24902-5-dg@adax.com> <20181024134602.5511fa0b@xeon-e3> <20181024141758.1302d77b@xeon-e3> In-Reply-To: <20181024141758.1302d77b@xeon-e3> From: Dan Gora Date: Wed, 24 Oct 2018 18:45:58 -0300 Message-ID: To: Stephen Hemminger Cc: dev@dpdk.org, Igor Ryzhov , Ferruh Yigit Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH v6 4/5] examples/kni: add log msgs to show and clear stats X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2018 21:46:35 -0000 On Wed, Oct 24, 2018 at 6:18 PM Stephen Hemminger wrote: > > > > > > This seems like an overly wordy message which should really be in the documentation > > > not a billboard in the code. > > > > > > In my opinion, having verbose messages is unhelpful since it just clutters > > > the experience. > > > > Sigh... > > > > This is version 6 of this patch. You could have said something about > > it at any point in the last two and a half months that I have been > > struggling to get this merged. > > > > These "features" were never documented at all, so you would have no > > idea they existed unless you read the code. > > > > The point of this patch is that you can just copy and paste the > > commands directly from the screen. This saves you from having to type > > 'ps -ef|grep kni', cut the PID, type 'kill -SIGUSR1', then paste the > > PID. How is that easier that what I have done? > > > > And it's not a billboard, it's 7 lines. Have you actually tried it? > > > > The amount of nitpicking on these patches has been just incredible.. > > People get entire subsystems merged with 1/10th the hassle that I've > > been given to add one stupid function. It's extremely frustrating. > > I've totally given up on trying to get my other KNI patches merged.. > > It's just not worth it.. > > > > dan > > I look at patches as they show up and don't want to overwhelm people > with a long laundry list of items. Just a case of call them as I see them. I personally, and I would imagine that most people, would prefer to get a long list of items to fix so that they can all be fixed at one time rather than this endless churning on the mailing list and the overhead of source control, formatting the patches, sending the patches, etc... > Often a developer is focused on "does my feature work" and misses how > the new feature is not used by most people. > > Remember when working on projects that the unstated policy is that all > code should look the same. Anything you introduce should look like everything > around it. Yes, this limits taste and individual freedom, but if you want to > change things then doing it in new code is not the way to do it. By definition, to change things, you need new code. In my experience 99.9999% of users do not read the documentation. Engineers, and unix/linux engineers in particular, are notorious for being terrible UI developers. The KNI sample application has a *terrible* user interface. You run the application and.... nothing... no indication of what happened, no indication of what you should do, just some nonsensical EAL debug messages. I was just trying to give the user some sense that 1: the thing is actually running and doing something 2: there is something that you can do to interact with the application and 3: save myself from some extra typing. I figured that since I hate any extra typing that most other people would as well. As far as it looking like everything around it; there was nothing around it before, so there's nothing to compare it against... I *could* have implemented a full menu thing like testpmd, but my objective here was not to fix the KNI sample app, it was just to add rte_kni_update_link(). That's all I really wanted... > The patch can go in as is. There is no reason for a message to block that. > Just trying to see what can be improved. > > Don't get disheartened, 6 versions of a patch is nothing bad. > Sometimes it takes 20 or more until agreement occurs. In the 6 months or so that I've been actively working on DPDK, I've never seen one, especially to add one, basically trivial, function. Two patches that caused compilation errors got merged in the last couple of weeks. I'll send a version 7 and add these commands to the documentation in the other patch [3/5].. You guys can accept or reject this patch [4/5]...