GUID partition types *are* of use to all. I see no problem keeping track of additional proprietary ids that are in the wild.
These are the type codes we use when partioning and examining partition tables, it is useful to know what a partition is even if we cannot read it. The referenced commit by Allan included ids for Microsoft proprietary partitions. This request seems in line with that to me. On January 11, 2016 12:19:34 AM EST, Marcelo Araujo <araujobsdp...@gmail.com> wrote: >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 <rpok...@mac.com>: > >> 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: <owner-src-committ...@freebsd.org> on behalf of Allan Jude >> <allanj...@freebsd.org> >> Date: 2015-12-27, Sunday at 10:12 >> To: <src-committ...@freebsd.org>, <svn-src-all@freebsd.org>, < >> svn-src-h...@freebsd.org> >> 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: <owner-src-committ...@freebsd.org> on behalf of "Andrey V. >Elsukov" >> <bu7c...@yandex.ru> >> Date: 2015-12-28, Monday at 00:32 >> To: Allan Jude <allanj...@freebsd.org>, <src-committ...@freebsd.org>, >< >> svn-src-all@freebsd.org>, <svn-src-h...@freebsd.org> >> 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: <owner-src-committ...@freebsd.org> on behalf of Konstantin >Belousov >> <kostik...@gmail.com> >> Date: 2015-12-28, Monday at 02:49 >> To: "Andrey V. Elsukov" <bu7c...@yandex.ru> >> Cc: Allan Jude <allanj...@freebsd.org>, <src-committ...@freebsd.org>, >< >> svn-src-all@freebsd.org>, <svn-src-h...@freebsd.org> >> 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@) >> >> _______________________________________________ >> svn-src-h...@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/svn-src-head >> To unsubscribe, send any mail to >"svn-src-head-unsubscr...@freebsd.org" >> > > > >-- > >-- >Marcelo Araujo (__)ara...@freebsd.org >\\\'',)http://www.FreeBSD.org <http://www.freebsd.org/> \/ \ ^ >Power To Server. .\. /_) >_______________________________________________ >svn-src-h...@freebsd.org mailing list >https://lists.freebsd.org/mailman/listinfo/svn-src-head >To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org" -- Sent from my Android device with K-9 Mail. Please excuse my brevity. _______________________________________________ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
