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