From owner-svn-src-head@freebsd.org Mon Jan 11 04:54:56 2016 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9FF8FA6B59B; Mon, 11 Jan 2016 04:54:56 +0000 (UTC) (envelope-from rpokala@mac.com) Received: from mr11p00im-asmtp001.me.com (mr11p00im-asmtp001.me.com [17.110.69.252]) (using TLSv1.2 with cipher DHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8CE5B1951; Mon, 11 Jan 2016 04:54:56 +0000 (UTC) (envelope-from rpokala@mac.com) Received: from [192.168.1.4] (c-24-6-178-251.hsd1.ca.comcast.net [24.6.178.251]) by mr11p00im-asmtp001.me.com (Oracle Communications Messaging Server 7.0.5.36.0 64bit (built Sep 8 2015)) with ESMTPSA id <0O0R00FW1UZB6Z30@mr11p00im-asmtp001.me.com>; Mon, 11 Jan 2016 04:54:50 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-01-11_03:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1011 suspectscore=17 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1510270003 definitions=main-1601110095 User-Agent: Microsoft-MacOutlook/0.0.0.151217 Date: Sun, 10 Jan 2016 20:54:46 -0800 Subject: Re: svn commit: r292788 - in head/sys: geom/part sys From: Ravi Pokala Sender: "Pokala, Ravi" To: Allan Jude , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Message-id: <1F9E33A5-A9D7-44A9-9519-2A1593BFF990@panasas.com> Thread-topic: svn commit: r292788 - in head/sys: geom/part sys References: <201512271812.tBRICD3A044563@repo.freebsd.org> In-reply-to: <201512271812.tBRICD3A044563@repo.freebsd.org> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7bit X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 04:54:56 -0000 Hi folks, I have a Panasas-proprietary GPT UUID that I'd like to commit upstream. There's ~zero chance anyone outside of Panasas or our customers would ever see it, but we're trying to reduce gratuitous differences against upstream, and this is a good candidate. When I mentioned this at the November 2015 DevSummit, no one there objected. There was a recent change in this area, which brought up some questions. See below: -----Original Message----- From: on behalf of Allan Jude Date: 2015-12-27, Sunday at 10:12 To: , , Subject: svn commit: r292788 - in head/sys: geom/part sys >Author: allanjude >Date: Sun Dec 27 18:12:13 2015 >New Revision: 292788 >URL: https://svnweb.freebsd.org/changeset/base/292788 > >Log: > Add some additional GPT partition types > >... > > Differential Revision: https://reviews.freebsd.org/D3841 > >... > In that review, there was discussion about the sorting of aliases in (enum g_part_alias). It was originally thought that the aliases needed to be sorted, due to binary searching in g_part_alias_name(). It turned out that g_part_alias_name() did a linear search, so the list didn't strictly need to be sorted. But, there was talk of potentially switching to a binary search later, so Allan went with the sorted version. ae@ and kib@ voiced some concerns: From: on behalf of "Andrey V. Elsukov" Date: 2015-12-28, Monday at 00:32 To: Allan Jude , , , Subject: Re: svn commit: r292788 - in head/sys: geom/part sys > This enum could be used by third-party kernel module and in general it > is not good to change the order of elements here. This can break `gpart > show` output for such modules. Just for the future. :) From: on behalf of Konstantin Belousov Date: 2015-12-28, Monday at 02:49 To: "Andrey V. Elsukov" Cc: Allan Jude , , , Subject: Re: svn commit: r292788 - in head/sys: geom/part sys > If the enum values are considered part of KBI, then explicit assignment > of the enum values is much preferred. As best as I can tell, nothing in base/head or ports/head looks at the GPT UUIDs or aliases (outside of GEOM_PART itself, of course), so ae@ and kib@'s concerns are not an issue at this time. Therefore, my plan is to insert the new alias and UUID entries into the various enums and lists in-order, rather than just appending. Any objections? Thanks, Ravi (rpokala@)