On Mon, 13 Jun 2005, Allen Briggs wrote:
>>  * just add an #ifdef for a symbol around the code, and keep the
>>    data fields for compression handling in struct vnd_softc
>
> Is there a good reason for leaving the data fields around?  (LKM
> issues if the structure is shared with other parts of the kernel;
> userland interface issues if the structure is shared with userland)

I looked a bit, and it seems the vnd_softc(sp?) is only used inside the 
kernel, it's also protected by an appropriate #ifdef in the vndvar.h 
header. And as the vnd(4) driver is unlikely to interoperate with some 
other LKM (I hope?), I think it's safe to also include the data in the 
softc conditionally.


>>  * put the #ifdef also on the fields in struct vnd_softc
>>  * use something else than an #ifdef/option (I have no idea on kernel
>>    hacking :)
>
> Use the config(9) 'defflag', I think.

Done, nifty stuff. :)


>> Thinking more about the userland tool's name, I wonder if "vndcompress"
>> would be more appropriate than cl<something>...
>
> I apologize if I missed something earlier, but is this something that
> could be folded into vnconfig ?

The tool compresses & uncompresses a disk-image (file), and isn't all that 
different from what compress/gzip etc. do - I don't feel like we should 
add this into vnconfig(8). Of course it could be done, but it would sound 
more like a hack to me (and the -c(ompress)/-u(ncompress) flags are 
already taken in vnconfig(8) ;-).

I'd leave it as seperate tool.


FWIW, the latest version of my patch is here (!!! beware, there are some 
bugs in there according to the author, Cliff Wright, which will raise a 
few problems !!!):

 	http://www.feyrer.de/Misc/vnd.gz-HF20050614.patch


  - Hubert