RFC: backporting GEOM to the 4.x branch
Robert Watson
rwatson at FreeBSD.org
Fri Feb 4 10:41:01 PST 2005
On Thu, 3 Feb 2005, ALeine wrote:
> rwatson at 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
More information about the freebsd-hackers
mailing list