From owner-svn-src-all@FreeBSD.ORG Mon Oct 29 06:52:59 2012 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CB9B4AC8; Mon, 29 Oct 2012 06:52:59 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail03.syd.optusnet.com.au (mail03.syd.optusnet.com.au [211.29.132.184]) by mx1.freebsd.org (Postfix) with ESMTP id E70FF8FC08; Mon, 29 Oct 2012 06:52:58 +0000 (UTC) Received: from c122-106-175-26.carlnfd1.nsw.optusnet.com.au (c122-106-175-26.carlnfd1.nsw.optusnet.com.au [122.106.175.26]) by mail03.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q9T6qsmt021991 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 29 Oct 2012 17:52:55 +1100 Date: Mon, 29 Oct 2012 17:52:54 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Juli Mallett Subject: Re: svn commit: r242276 - head/sys/mips/cavium In-Reply-To: <201210290210.q9T2AKOd052811@svn.freebsd.org> Message-ID: <20121029173544.Y1261@besplex.bde.org> References: <201210290210.q9T2AKOd052811@svn.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-Cloudmark-Score: 0 X-Optus-Cloudmark-Analysis: v=2.0 cv=F/YP7ddN c=1 sm=1 a=wBP4FV5UvGQA:10 a=kj9zAlcOel0A:10 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=4HK1B-gzULkA:10 a=7nL5cK90jzteqgzt_1EA:9 a=CjuIK1q_8ugA:10 a=-W88bXlIhmuAOjfG:21 a=mCyrQilsO2o-PBxE:21 a=bxQHXO5Py4tHmhUgaywp5w==:117 Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 06:52:59 -0000 On Mon, 29 Oct 2012, Juli Mallett wrote: > Log: > Wrap some long lines and display board serial numbers at boot. Any chance of using FreeBSD style instead of gnu style for the wrapping? > Modified: head/sys/mips/cavium/octeon_machdep.c > ============================================================================== > --- head/sys/mips/cavium/octeon_machdep.c Mon Oct 29 01:51:24 2012 (r242275) > +++ head/sys/mips/cavium/octeon_machdep.c Mon Oct 29 02:10:20 2012 (r242276) > @@ -512,14 +512,19 @@ octeon_process_app_desc_ver_6(void) > octeon_bootinfo->board_rev_major, > octeon_bootinfo->board_rev_minor, > octeon_bootinfo->eclock_hz); This old wrapping uses gnu style (indent -lp). The struct member names in it are verbose, but not verbose enough to have normal style with a struct-dependent prefix. > - memcpy(cvmx_sysinfo_get()->mac_addr_base, octeon_bootinfo->mac_addr_base, 6); > + memcpy(cvmx_sysinfo_get()->mac_addr_base, > + octeon_bootinfo->mac_addr_base, 6); This new wrapping is in gnu style. FreeBSD style is indent -ci4. > cvmx_sysinfo_get()->mac_addr_count = octeon_bootinfo->mac_addr_count; > cvmx_sysinfo_get()->compact_flash_common_base_addr = > octeon_bootinfo->compact_flash_common_base_addr; > cvmx_sysinfo_get()->compact_flash_attribute_base_addr = > octeon_bootinfo->compact_flash_attribute_base_addr; The last 2 wrappings aren't in either gnu style or FreeBSD style. FreeBSD style is indent -ci4 again. Gnu style is to put the operator on the new line, and IIRC, line up the operator with the variable, resulting in no indentation for the operator. This has the FreeBSD style for the operator, but a contination indent of 8. > cvmx_sysinfo_get()->core_mask = octeon_bootinfo->core_mask; > - cvmx_sysinfo_get()->led_display_base_addr = octeon_bootinfo->led_display_base_addr; > + cvmx_sysinfo_get()->led_display_base_addr = > + octeon_bootinfo->led_display_base_addr; This matches the above for neither gnu not FreeBSD style. > + memcpy(cvmx_sysinfo_get()->board_serial_number, > + octeon_bootinfo->board_serial_number, > + sizeof cvmx_sysinfo_get()->board_serial_number); This matches the above for the gnu style of the indentation. It also doesn't follow FreeBSD style for the explicit "sizeof is not followed by a space" or the implicit "sizeof is followed by a left parentheses (without a space)". The former implies the latter, because the identifiers would coalesce without the space. My normal style would omit the parentheses for `sizeof object' and everywhere else possible, but here they are needed for another reason for people who like excessive parentheses: the pointer is returned by a function so it has parentheses in it, so it is not as clear as usual what the object is. Bruce