Herbert Valerio Riedel wrote: > On Fri, 2002-03-15 at 18:36, Jari Ruusu wrote: > > Not changing IV parameter type in 2.4 kernels is important. Break that in > > 2.5/2.6 kernels, but not in stable 2.4, ok? > > if you look closely at the typedef above, you'll notice that it doesn't > introduce a _new_ type, but only a synonym for the 'int' type, which > happens to be the type used in 2.4 kernels... A synonym that does not exist on older kernels. > typedef int (* transfer_proc_t)(struct loop_device *, int cmd, > char *raw_buf, char *loop_buf, int size, > int real_block); ^^^ That function prototype _must_ _not_ change in 2.4 kernels. That 'int' better be there on newer 2.4 kernels. > > Older 2.4 kernels dont't have > > loop_iv_t, and being able to compile _existing_ modules for them is > > important. > as older kernels will likely have the variable-IV-metric, they'll have > to be patched anyway (loop.[ch]), and after having patched them, the > problem vanishes... If you haven't noticed, loop-AES compiles and works fine on older kernels without changing anything in kernel sources. > > So the choice here is either break (or at least cause need to modify) all > > other implementations or cryptoapi implementation. > actually it's just -- either make my life harder w/ cryptoapi or not, as > it doesn't affect other implementations; Transfer function prototype change does affect other implementations. I would have to add workaround to compile loop-AES on older kernels. If cryptoapi got one parameter wrong, I don't see why other implementations should bend over because of that. Herbert, if you need some special types and/or macros in cryptoapi, just define them in cryptoapi include files. Please don't mess with code that other implementations depend on. > > Herbert, if this loop_iv_t type goes into mainline kernel, I will have to > > reverse that on loop-AES patches for backward compatibility. > I don't see why... loop_iv_t is just a 'reviced-declarator-type-list > int', i.e. it is is type compatible w/ an 'int'... so you won't even > notice the difference when compiling loop-AES against it... What I do notice is having to add workaround. See, loop-AES only creates patched-loop.c (but not patched-loop.h), and under some circumstances patched-loop.c may come from newer code than loop.h. So it needs a workaround if transfer function prototype is changed. > > Dependency on above mentioned #define's/typedef on kernel include files is > > silly, as cryptoapi can define them on any of its own include files. > yeah, sure... at the expense of having to redundantly keep track (ugly > #ifdef's) of which kernel version is being used... If IV parameter type is changed from 32 bits to 64 bits, you will need new code and #ifdef's to handle that anyway. And that is 2.5/2.6 thing anyway. Regards, Jari Ruusu <jari.ruusu@pp.inet.fi> - Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/