On Tue, 2002-05-21 at 16:30, Tobias Ringstrom wrote: > A (good) change went in after patch-int-2.4.18.2 that made it possible to > detect the version of the API. ..you might mention, that you were the one who actually convinced me to add it ;) >> we are currently working on tracking down one major show stopper bug in >> the loop driver exposed when using XFS and SMP... if it weren't for the >> loop bug, there'd be already an official patch-int lying in >> /pub/linux/kernel/crypto/v2.4/ instead of it hiding in the testing >> folder... :-/ > Why not separate the releases? I'd like to see three packages: > 1. Crypto support (no algorithms). This can go into the official kernel, > at least once the API is stable. so far, the only possible thing that comes to my mind, that might cause changes in the API might be hardware cipher support... > 2. Crypto modules. Can probably not to inte the official kernel due to > crypto export regulations. Can be built outside the kernel tree to > avoid kernel patching. some people also suggested splitting the ciphers up into patented/non-patented, weak/strong, ... > 3. Encrypted loop driver. > > What do you think? good point... the crypto api itself almost kernel version independent, so it might well justify splitting it from the cryptoloop application, which is the biggest headache to keep in sync with the rest of the kernel... that's one of the reasons why I started to split off the loop-modifying stuff into a patch of it's own (loop-jari/hvr patches)... now I'll just have to figure out a way to accomplish the split without letting maintenance get unreasonable... 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
