Date: Fri, 4 Feb 2005 18:40:09 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: ALeine <aleine@austrosearch.net> Cc: freebsd-hackers@FreeBSD.org Subject: Re: RFC: backporting GEOM to the 4.x branch Message-ID: <Pine.NEB.3.96L.1050204180354.36476B-100000@fledge.watson.org> In-Reply-To: <200502032003.j13K3Vm7080654@marlena.vvi.at>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 3 Feb 2005, ALeine wrote: > rwatson@FreeBSD.org wrote: > > > I guess the interesting question is why to do this? <...> > Basically, it seems like I should save myself a lot of trouble and just > deGEOMify GBDE so it can be integrated into FreeBSD 4.x and DragonFly > BSD. I can live without GEOM GATE, but GBDE (or dGDE as it will probably > be called once I'm done botching it :->) is something I really really > need in 4.x. Would this be something the Core members would like to see > committed to RELENG_4? > > I would also appreciate it very much if you could give me some pointers > on deGEOMifying GBDE. There are basically two parts to GBDE: - A block transformation engine that performs cryptographic operations on in-flight I/O operations and configuration data. - A lot of administrative details involving discovery, configuration, registration, interposition in the I/O path, event engine, etc. GEOM basically provides 90%+ of the second part of this, since that's basically what it is: a framework for storage transforms, discovery, management, I/O, etc. So that's the bit you'll need to replace if you want to make it run on 4.x. What you may want to do is create a character device driver that resembles the md(4)/vn(4) mechanism: it consumes another file or device, forwards I/O from its own device node to the underlying device after performing the transformation. If possible, you'd want to attempt to provide a small and approximate subset of the GEOM API to GBDE so that you could leave GBDE as intact as possible. Regarding getting this into 4.x: I suspect the biggest concern would be forward compatibility issues. It would be substantially counter-productive to merge a feature back with a different interface/compatibility, as it would make forward upgrades harder. So if it were going to be merged to 4.x, it would need to use an identical on-disk format, and ideally configuration settings/switches/commands/etc. I would continue to encourage you to invest this non-trivial effort in making 5.x fit your needs, instead :-). Robert N M Watson
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1050204180354.36476B-100000>