Date: Thu, 3 Oct 2002 12:03:33 -0700 (PDT) From: Julian Elischer <julian@elischer.org> To: Bakul Shah <bakul@bitblocks.com> Cc: Bruce Evans <bde@zeta.org.au>, freebsd-hackers@FreeBSD.ORG Subject: Re: vmware reads disk on non-sector boundary Message-ID: <Pine.BSF.4.21.0210031155320.218-100000@InterJet.elischer.org> In-Reply-To: <200210031637.MAA01800@rodney.cnchost.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 3 Oct 2002, Bakul Shah wrote: > > It was desired, and was sort of promised. > > I never understood why removal of block devices was allowed > in the first place. phk's reasons don't seem strong enough > to any unix wizard I have talked to. Did the majority of the > core really think the change was warranted? Removing > compatibility when the change _doesn't_ bring a *substantial* > improvement doesn't seem right. He had some backing, for example Kirk made a good argument for removing them. The arguments about not being able to do devfs and geom without removing them are of course specious as it can and was done before by others. > > How hard would it be to bring back block devices without GEOM? Even WITH geom it would be possible. > > Is there a write up somewhere on what GEOM is and its > benefits? I'd hate to see it become the default without > understanding it (and no, reading source code doesn't do it). The concept is good. One provides a stacking system for disk geometries wand layouts where the upper interface is the same as that provided by the actual disk. Using devfs, one can export the 'top suface' of the stack as accessible devices. Theoretically the latyers can apply themselvces as a device is recognised and each layer type 'probes' the device to figure out it it belongs there. It's not rocket science as far as an idea goes. The trick is in the implementation. Locking and access control of parts gets quite tricky. for a similar idea look in the cvs tree for the now removed 'slice' code that did teh same thing. /sys/dev/slice It supported black and character device nodes for each partition. > > Thanks! > > -- bakul > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > 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?Pine.BSF.4.21.0210031155320.218-100000>