IMHO, if it can't be something generic that other people can use it, it is a NO GO!
-1 2016-01-11 12:54 GMT+08:00 Ravi Pokala <[email protected]>: > 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: <[email protected]> on behalf of Allan Jude > <[email protected]> > Date: 2015-12-27, Sunday at 10:12 > To: <[email protected]>, <[email protected]>, < > [email protected]> > 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: <[email protected]> on behalf of "Andrey V. Elsukov" > <[email protected]> > Date: 2015-12-28, Monday at 00:32 > To: Allan Jude <[email protected]>, <[email protected]>, < > [email protected]>, <[email protected]> > 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: <[email protected]> on behalf of Konstantin Belousov > <[email protected]> > Date: 2015-12-28, Monday at 02:49 > To: "Andrey V. Elsukov" <[email protected]> > Cc: Allan Jude <[email protected]>, <[email protected]>, < > [email protected]>, <[email protected]> > 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@) > > _______________________________________________ > [email protected] mailing list > https://lists.freebsd.org/mailman/listinfo/svn-src-head > To unsubscribe, send any mail to "[email protected]" > -- -- Marcelo Araujo (__)[email protected] \\\'',)http://www.FreeBSD.org <http://www.freebsd.org/> \/ \ ^ Power To Server. .\. /_) _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "[email protected]"
