From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1035012AbcIVVwP (ORCPT ); Thu, 22 Sep 2016 17:52:15 -0400 Received: from smtprelay0092.hostedemail.com ([216.40.44.92]:44189 "EHLO smtprelay.hostedemail.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1030343AbcIVVwM (ORCPT ); Thu, 22 Sep 2016 17:52:12 -0400 X-Session-Marker: 6A6F6540706572636865732E636F6D X-Spam-Summary: 2,0,0,,d41d8cd98f00b204,joe@perches.com,:::::,RULES_HIT:41:355:379:541:800:960:968:973:988:989:1260:1277:1311:1313:1314:1345:1373:1431:1437:1515:1516:1518:1534:1542:1593:1594:1711:1730:1747:1777:1792:2194:2199:2393:2553:2559:2562:2689:2828:3138:3139:3140:3141:3142:3353:3834:3865:3866:3867:3868:3871:3874:4321:4560:4605:5007:6238:7576:7903:8603:9121:9545:10004:10400:10848:10967:11233:11658:11783:11914:12043:12262:12296:12438:12555:12679:12740:13161:13229:13439:13870:13894:14181:14659:14721:21080:21433:21451:30054:30090:30091,0,RBL:none,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:fn,MSBL:0,DNSBL:none,Custom_rules:0:0:0,LFtime:3,LUA_SUMMARY:none X-HE-Tag: smoke51_12f2483d42f35 X-Filterd-Recvd-Size: 3075 Message-ID: <1474581128.8253.35.camel@perches.com> Subject: rfc: Are any of the seq_pad() uses really necessary? From: Joe Perches To: netdev Cc: Tetsuo Handa , LKML Date: Thu, 22 Sep 2016 14:52:08 -0700 Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.21.91-1ubuntu1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org $ git grep -w seq_pad net net/ipv4/fib_trie.c:            seq_pad(seq, '\n'); net/ipv4/ping.c:        seq_pad(seq, '\n'); net/ipv4/tcp_ipv4.c:    seq_pad(seq, '\n'); net/ipv4/udp.c: seq_pad(seq, '\n'); net/phonet/socket.c:    seq_pad(seq, '\n'); net/phonet/socket.c:    seq_pad(seq, '\n'); net/sctp/objcnt.c:      seq_pad(seq, '\n'); what these uses do is add trailing blanks to a particular preset block width and then append a newline. None of these trailing pad bytes seem useful to me. Are there really tools that expect specific line widths when reading from things like /proc//net/ For instance: $ cat /proc//net/udp sl local_address rem_address st tx_queue rx_queue tr tm->when retrnsmt uid timeout inode ref pointer drops 484: 00000000:14E9 00000000:0000 07 00000000:00000000 00:00000000 00000000 111 0 16961 2 0000000000000000 0 486: 00000000:14EB 00000000:0000 07 00000000:00000000 00:00000000 00000000 102 0 2022599 2 0000000000000000 0 788: 00000000:A619 00000000:0000 07 00000000:00000000 00:00000000 00000000 1000 0 4390482 2 0000000000000000 0 3081: 00000000:8F0E 00000000:0000 07 00000000:00000000 00:00000000 00000000 111 0 16963 2 0000000000000000 0 3376: 3500007F:0035 00000000:0000 07 00000000:00000000 00:00000000 00000000 102 0 2022601 2 0000000000000000 0 3391: 00000000:0044 00000000:0000 07 00000000:00000000 00:00000000 00000000 0 0 4546167 2 0000000000000000 0 These seq_pad uses were modified by: >>From 652586df95e5d76b37d07a11839126dcfede1621 Mon Sep 17 00:00:00 2001 From: Tetsuo Handa Date: Thu, 14 Nov 2013 14:31:57 -0800 Subject: [PATCH] seq_file: remove "%n" usage from seq_file users All seq_printf() users are using "%n" for calculating padding size, convert them to use seq_setwidth() / seq_pad() pair. Signed-off-by: Tetsuo Handa Signed-off-by: Kees Cook Cc: Joe Perches Cc: David Miller Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds If these are really necessary, then maybe the seq_pad function could be optimized using a memset instead of seq_printf(, "%*s", len, "");