On Mon, January 7, 2013 07:23, Yves-Alexis Perez wrote: > On dim., 2013-01-06 at 17:24 +0100, Milan Broz wrote: >> > Is this really the proper fix? Usually, userland needing headers >> more >> > recent than what's in linux-libc-dev should embed them, and >> correctly >> > handle at runtime if the interfaces are available. >> >> These are two separate problems >> - you need to compile it on system where new header/kernel is not >> available >> - you need to detect that current kernel is not able to use >> userspace crypto API interface (this includes missing module etc.) >> >> Both should be handled already. >> >> > What happens here if cryptsetup is built on a recent enough kernel >> where >> > the header is present, and then run on an old kernel? Will it fail >> > gracefully? >> >> It should print something like >> ... >> Required kernel crypto interface not available. >> Ensure you have algif_skcipher kernel module loaded. > > Good. And what happens if cryptsetup is built on an old box not having > recent enough headers (typically a buildd) but is run on a box with > recent kernels? I guess there's no support, while, when headers are > embedded, they would be available. > > Regards, > -- > Yves-Alexis Exactly, when the header is missing, you can hardly compile support in, as the compiler does not know the interface. Putting the header into cryptsetup package is not an option, as it is not part of cryptsetup itself, but merely the kernel and possibly changes from time to time. Usually, a package describes its dependencies and then the builder's job is to provide an adequate build environment to get the build he wants. Regards -Sven _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
