HEADS UP! Compatibility slice will no longer point at the first BSD slice
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?
<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