Date: Tue, 29 Oct 2002 22:27:35 +0100 From: Poul-Henning Kamp <phk@critter.freebsd.dk> To: Marcel Moolenaar <marcel@xcllnt.net> Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/lib/libdisk Makefile chunk.c disk.c libdisk.h rules.c Message-ID: <98377.1035926855@critter.freebsd.dk> In-Reply-To: Your message of "Tue, 29 Oct 2002 12:43:41 PST." <20021029124341.A76240@kayak.xcllnt.net>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <20021029124341.A76240@kayak.xcllnt.net>, Marcel Moolenaar writes: >On Tue, Oct 29, 2002 at 04:13:36AM -0800, Poul-Henning Kamp wrote: >> >> Modified files: >> lib/libdisk Makefile chunk.c disk.c libdisk.h rules.c >> Log: >[snip] >> >> I need to sort out alpha, pc98 and ia64 (in that order) before >> testing on those platforms make a lot of sense. >GPT based systems like ia64 probably need some fundamental changes. >Tools like fsck(8) require a disklabel to figure out the partition >type. No actually fsck tries to guess the filesystem type and only uses the disklabel if /etc/fstab fails to answer the question. Sparc64 has no disklabel either and fsck should just be muffled to not whine if the disklabel check fails: BSD disklabels are optional now. >But the state on (at least my) ia64 is that it's pure GPT, booting >fine and sorely in need of having sysinstall and fsck(8) working :-) Wheee! :-) I wont have much time to help you out before 5.0, but feel free to throw questions at me if you want to try to tackle this yourself. You should be able to use the path though libdisk which I have just cleared for sparc64 and alpha. The interface to the kernel is about as generic as I can do it, and with a little luck you may need no more than 10 lines of code in libdisk:disk.c to fill in the right details. You need to write a write_ia64_disk.c which writes GPT, and that is probably the worst bit. The situation is probably worse over in sysinstall, because you need a mix of both screens if we want to co-exist with other OS's: Only the "MBR" screen can understand "not ours" chunks of disk, and only the "LABEL" screen can assign mountpoints and all that. Ideally, we should have one combined screen for this, but we don't, and I doubt we will have for 5.0-R (even though alpha and sparc64 could use it with great benefit too, but they are less likely to have multiple OS's on the same physical disk). I will suggest that you fake it in the following way: Go into the MBR screen, and let people operate on the GPT partitions like they would on MBR slices, have people create all FreeBSD parititions here. Next, send them to the Label screen but disable all size/create/delete options, and use it only for assigning mountpoints, ufs options etc. This is far from optimal, and will be different from what people are used to, but it will be possible to implement it on a crash-schedule before 5.0. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?98377.1035926855>