HEADS UP! Compatibility slice will no longer point at the first BSD slice

Bill Hacker wbh at conducive.org
Sat Jun 16 21:13:10 PDT 2007

Matthew Dillon wrote:
:    The compatibility slice (s0) will no longer point at the first BSD slice
:    in the upcoming commit.  This should not effect anyone as nobody uses
:    the compatibility slice in that manner any more.
:    This change is necessary because to implement GPT partitions, which I've
:    decided will be abstracted as slices, I want GPT partition #0 to 
:    be s0, GPT partition #1 to be s1, and so forth to avoid confusion.

    Hmm.  I need some help.  The documentation for EFI says the partition
    numbers start at 0, but the FreeBSD GPT program seems to start numbering
    them at 1.
    Does anyone know how Linux interprets the partition numbers for a GPT?

					Matthew Dillon 
					<dillon at backplane.com>
I'm not where I can look it up, but ISTR Linux starts with the 'zeroth' 
partition - GPT or otherwise.

Your previous post w/r 'reserved' compatibility slice 0 explains (finally) why 
FreeBSD has always appeared to 'start' with 1. Seems there is/was a method to 
their apparant inconsistency after all?

'Spose I'd have known that if I ran anything that neeed a 'compatibility' slice.

W/R going GPT-way or legacy FreeBSD way - perhaps use of zeroth should be 
weighed vis whatever FreeBSD 7.X is doing?

I mean - with whom/what/(anything?) should DFLY try for compatibility?



More information about the Kernel mailing list