Re: 2.4.19pre3aa2

[Jari Ruusu]

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 <[e-mail]>