DragonFly kernel List (threaded) for 2005-02
Re: RFC: backporting GEOM to the 4.x branch
> 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.
I have been examining the GEOM code and at this point it seems that
creating a subset of the GEOM API in order to leave GBDE intact would
take more effort than ripping the cryptographic mechanism out of GBDE
and integrating it into vn(4).
Speaking of examining code, do you guys use data flow diagrams
and other visual representation systems so you can work more quickly
and effectively on such a huge and complex code base?
I'm using doxygen and graphviz and I have to say they're really great,
as can be seen from the following g_bde_work struct example:
The rest can be found at:
This sort of detailed visual documentation would allow faster development
while also making it easier for new developers to join the project. What
do you guys think about having such documentation for the entire source
tree available on the web? Having the docs regenerated automatically once
a day would probably be sufficient to be useful.
> 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
That is another reason why I think I should isolate the whole thing
by creating a cryptographic character device driver (cvn(4)). It would
also make it easier to port to DragonFly BSD.
WebMail FREE http://mail.austrosearch.net