Date: Mon, 27 Jan 2003 00:35:36 -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: <20030127083536.GA2644@dhcp01.pn.xcllnt.net> In-Reply-To: <19313.1043652737@critter.freebsd.dk> References: <20030127070958.GA2431@dhcp01.pn.xcllnt.net> <19313.1043652737@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030127083536.GA2644>