Julian Elischer wrote: > > > On Mon, 13 Jan 2003, walt wrote: > > > [EMAIL PROTECTED] wrote: > > > Julian Elischer writes: > > > > > >>I think that one of the things we need to do is declare a new flag in > > >>disklabel that declares that the disklabel has been converted to use > > >>relative offsets... > > > > > Better plan: Abandon BSD labels before disks outgrow them. > > > > To be replaced by....what? > > gpt > I don't know where it comes from but I believe it's the native partition > format for ia64 architecture machines.
Pros: - fully 64 bit clean - maximum of 16384 partitions - unique id's for disks, partitions and OS types. - we already have the basic code support for it in the tree. - its on intel's roadmap for future i386 servers (for what thats worth) along with EFI. - it is possible to boot from, but needs new boot code written(*). Cons: - If you follow the spec strictly, it will not share disks with another fdisk-using OS. If strictly implemented according to the specs, it replaces the fdisk MBR and owns the entire disk. Our code however isn't that strict and will accept a GPT inside an MBR slice, meaning for i386 we can use GPT as a replacement for disklabel. - Booting is "interesting"(*). * - When GPT is used with EFI, the firmware has got a mini OS in rom which has native FAT32 file system support, which means we can just mount the boot partition and copy "loader.efi" in there and there are *no* bootblocks.. However, if we were to use it standalone we would not have this and would have to boot ourselves. The way this would be done is to put real boot code in the MBR, which would scan the gpt table to find a boot "partition" that contained the equivalent of what is now boot2. We could make this as big as we liked, but I'd imagine it would be 64K by default. That boot2 code would then be able to read UFS natively, just like now. In other words, it wouldn't be all that different to now except that somebody has to write it. Alternatively, we could deviate a bit from the "strict" specs and reserve the entire first track for boot code and avoid the problem that way. This would be easier and less likely to run into major code space pressure problems as it wouldn't have to parse GPT tables. Personally, unless EFI on i386 actually gets off the ground, if somebody is seriously considering this, I'd be inclined to suggest using a fairly loose gpt interpretation and using gpt as a replacement for disklabel inside a freebsd slice. That way it is easy to "play nice" with other OS's and less pain to deal with for booting. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
