On Wed, Oct 24, 2018 at 6:18 PM Stephen Hemminger <step...@networkplumber.org> 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]...
