From owner-cvs-all Mon Jan 27 0:35:39 2003 Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0C39737B401; Mon, 27 Jan 2003 00:35:38 -0800 (PST) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1DB2743ED8; Mon, 27 Jan 2003 00:35:37 -0800 (PST) (envelope-from marcel@xcllnt.net) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by ns1.xcllnt.net (8.12.6/8.12.6) with ESMTP id h0R8ZaMW057135; Mon, 27 Jan 2003 00:35:36 -0800 (PST) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp01.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp01.pn.xcllnt.net (8.12.6/8.12.6) with ESMTP id h0R8ZaXC002780; Mon, 27 Jan 2003 00:35:36 -0800 (PST) (envelope-from marcel@dhcp01.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.12.6/8.12.6/Submit) id h0R8Zaki002779; Mon, 27 Jan 2003 00:35:36 -0800 (PST) (envelope-from marcel) Date: Mon, 27 Jan 2003 00:35:36 -0800 From: Marcel Moolenaar To: phk@freebsd.org Cc: Nate Lawson , cvs-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/sbin/disklabel disklabel.c Message-ID: <20030127083536.GA2644@dhcp01.pn.xcllnt.net> References: <20030127070958.GA2431@dhcp01.pn.xcllnt.net> <19313.1043652737@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <19313.1043652737@critter.freebsd.dk> User-Agent: Mutt/1.5.3i Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Jan 27, 2003 at 08:32:17AM +0100, phk@freebsd.org wrote: > In message <20030127070958.GA2431@dhcp01.pn.xcllnt.net>, Marcel Moolenaar write > s: > > >One of the thoughts I have on the issue is to have the geom classes > >have device nodes as side-entrances, independent of the producer- > >consumer interfaces. Direct access to the device nodes can then > >easily be checked with each read or write without pessimizing the > >P/C layering. > > > >The ioctl interface not not suited for GPT as the amount of data that > >has to be read or written is not fixed, as are the LBAs at which the > >data has to be written. > > Well, that doesn't really mean that ioctl cannot be used, merely > that the arguments have to be taylored. True, but why do we want to create an artificial interface on top of ioctl(2) or by means of ioctl(2), that's less suitable than the existing read(2), write(2) and lseek(2) mechanism, which BTW is in use by gpt(8) already? When we talked about this more than 6 months ago (IIRC) you suggested the use of a sysctl (which is roughly equivalent to an ioctl) to enable foot-shooting. That would be an acceptable solution IMO. Using ioctl (or sysctl for that matter) to implemement an alternate read- write interface for single sector boot blocks at fixed LBAs is getting ugly, but one could get away with it. Trying to implement an alternate read/write interface that's as flexible as existing interfaces to handle GPT is a bad idea and volates POLA. And all this because we haven't got the infrastructure in the kernel to deal with permissions without pessimizing disk I/O? Sorry, that doesn't seem right to me... -- 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