Date: Wed, 17 Jun 1998 11:19:28 -0500 From: Greg Lehey <grog@lemis.com> To: Mike Smith <mike@smith.net.au> Cc: Bruce Evans <bde@zeta.org.au>, FreeBSD Hackers <hackers@FreeBSD.ORG> Subject: Re: cvs commit: src/sys/dev/slice slice_base.c Message-ID: <19980617111928.14575@papillon.lemis.com> In-Reply-To: <199806170449.VAA00856@antipodes.cdrom.com>; from Mike Smith on Tue, Jun 16, 1998 at 09:49:02PM -0700 References: <19980615131558.32993@papillon.lemis.com> <199806170449.VAA00856@antipodes.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 16 June 1998 at 21:49:02 -0700, Mike Smith wrote: >> (moved from cvs-* to -hackers) >> >> On Mon, 15 June 1998 at 18:10:58 +1000, Bruce Evans wrote: >>>> No, disklabel depends on the 'old' slice ioctls, which are dead and >>>> gone. We're still stuck waiting on the new toolchain, although if >>> >>> No, disklabel depends on the very old label ioctls, which are standard. >> >> I have to agree on this one. Individual programs should make no >> assumptions about the location of a disk label. It could even be >> stored separately, so that reading the slice could never return the >> label. Does anybody have objections to the "old" ioctls? > > Hmm. I'd have to say that the major problem is that the disklabel > ioctls only deal with disklabels. These were extended later when the > slice stuff came in, but the "new paradigm" would make this a little > amusing (you could slice a partition which was part of a slice... ad > infinitum). I'm not sure what you're trying to say here. This is exactly the reason for using the ioctls. They could be generated by an intermediate layer, for example, and not stored anywhere on disk. Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980617111928.14575>