Date: Mon, 27 Jan 2003 02:45:55 -0800 From: Marcel Moolenaar <marcel@xcllnt.net> To: phk@freebsd.org Cc: Nate Lawson <nate@root.org>, cvs-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/sbin/disklabel disklabel.c Message-ID: <20030127104555.GA3050@dhcp01.pn.xcllnt.net> In-Reply-To: <21120.1043661235@critter.freebsd.dk> References: <20030127095004.GA2876@dhcp01.pn.xcllnt.net> <21120.1043661235@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jan 27, 2003 at 10:53:55AM +0100, phk@freebsd.org wrote: > > I simply meant that the geom_gpt.c class should create two providers > which correspond to the applicable ranges of the consumer. > > Those two would show up in /dev as "ad0.gpt0" and "ad0.gpt1" or > whatever you decide to call them, and you can open/read/write them > as much as you like: no need for ioctls. This is just a variant of alternate interfacing because the gpt(8) tool must to open /dev/ad0 when no gpt partitioning is created and no applicable ranges exist, can open /dev/ad0 or both /dev/ad0.gpt(0|1) when partitions exist but none are mounted and must open /dev/ad0.gpt(0|1) when partitions are mounted. Added to this the complexity of actually stat'ing and making sure that if ad0.gpt0 exists, ad0.gpt1 exists as well (and vice versa). Not to mention the kludgery to continue supporting regular files which do allow all GPT munging on a single file descriptor :-( Now, to top this off: This obviously ignores the not uncommon case of not being able to open /dev/ad0 for writing when MBR partitions are mounted and no GPT exists (and hence /dev/ad0.gpt(0|1) do not exist) because we're trying to migrate from MBR to GPT. Since we apparently go for the context specific and limited interfaces, we run into walls we create for ourselves. Ergo: we need an ioctl that's capable of general I/O if we want to avoid fixing the problem and allow migrating from MBR to GPT. This annihilates the work-around of creating 2 device nodes and brings us back to the point where I entered the discussion and said that ioctls are not suitable for generic I/O. Clearly this isn't getting anywhere and you also don't give any reason whatsoever why fixing geom is not an option. So, at this time I can only conclude that there are non-technical forces at work... this is where I step out of the discussion and into bed... -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net 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?20030127104555.GA3050>