hello!
On Fri, 2002-03-15 at 18:36, Jari Ruusu wrote:
> > /* definitions for IV metric */
> > #define LOOP_IV_SECTOR_BITS 9
> > #define LOOP_IV_SECTOR_SIZE (1 << LOOP_IV_SECTOR_BITS)
> >
> > typedef int loop_iv_t;
> 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...
typedef int (* transfer_proc_t)(struct loop_device *, int cmd,
char *raw_buf, char *loop_buf, int size,
int real_block);
what I'm trying to do by the introduction of this _aesthetic_ syntactic
element, is to prepare the way to smoothly upgrade the type used for the
IV value; and more important to keep filter modules from having to add
ugly #ifdef LINUX_VERSION_CODE <= KERNEL(2,X,Y)... just for changes
which could be catched by kernel headers...
have you ever wondered, why even the C standard defines some typedefs as
size_t instead of using just a 'long'?
> 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...
>> ps: just to make one thing clear (again), I don't care too much whether
>> my loop-fix or jari's goes in; I primarily care for a fixed IV situation
>> (including the above mentioned #define's/typedef) and if possible anyhow
>> to allow for limited compatibility to the old metric...
> 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; but other implementations may
start to use those typedefs in the future, so when 2.6 (or whatever
comes out) the 'current' 2.6 has them already, and the 'ultra-stable'
2.4's will have them as well... and maybe everybody is happy, that he
can compile the same c source against both, 2.4 and 2.6, loop.h and
still get a correct filter module...
> 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...
> 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...
another reason I haven't mentioned so far is about the #define's;
#define LOOP_IV_SECTOR_BITS 9
#define LOOP_IV_SECTOR_SIZE (1 << LOOP_IV_SECTOR_BITS)
...if you don't see any reason for those 2 innocent #define then you
won't see any reason for other #define in the kernel headers as well;
e.g.:
fs.h:
#define BLOCK_SIZE_BITS 10
#define BLOCK_SIZE (1<<BLOCK_SIZE_BITS)
you may ask why those are used, since they are hardcoded anyway... well,
lemme show you an example where this would considerably help:
loop.c:
static unsigned long compute_loop_size(struct loop_device *lo, struct
dentry * lo_dentry, kdev_t lodev)
{
if (S_ISREG(lo_dentry->d_inode->i_mode))
return (lo_dentry->d_inode->i_size - lo->lo_offset) >> BLOCK_SIZE_BITS;
if (blk_size[MAJOR(lodev)])
return blk_size[MAJOR(lodev)][MINOR(lodev)] -
(lo->lo_offset >> BLOCK_SIZE_BITS);
return MAX_DISK_SIZE;
}
and now imagine the same source fragment, with the #define's
evaluated... wouldn't that be less self-explaining?
well, I hope I could make clear to you, why using symbolic constants and
the use of typedefs in C are good practice in general wrt software
engineering...
regards,
--
Herbert Valerio Riedel / Phone: (EUROPE) +43-1-58801-18840
Email: hvr@hvrlab.org / Finger hvr@gnu.org for GnuPG Public Key
GnuPG Key Fingerprint: 7BB9 2D6C D485 CE64 4748 5F65 4981 E064 883F
4142
Attachment:
signature.asc
Description: This is a digitally signed message part
