[ trimmed the cc ] On 6/26/07, Satyam Sharma <satyam.sharma@xxxxxxxxx> wrote:
Hi Dan, [ Minor thing ... ]
Not a problem, thanks for taking a look...
On 6/27/07, Dan Williams <dan.j.williams@xxxxxxxxx> wrote: > The async_tx api tries to use a dma engine for an operation, but will fall > back to an optimized software routine otherwise. Xor support is > implemented using the raid5 xor routines. For organizational purposes this > routine is moved to a common area. This isn't quite crypto code and isn't connected to or through the cryptoapi (at least not in this patchset), so I somehow find it misplaced in the crypto/ directory. If all its users are in drivers/md/ then that would be a better place. If it is something kernel-global, lib/ sounds more appropriate?
True, it isn't quite crypto code, but I gravitated to this location because: 1/ the models are similar, both are general purpose apis with a driver component 2/ there are already some algorithms in the crypto layer that are not strictly cryptographic like crc32c, and other checksums 3/ having the code under that directory is a reminder to consider closer integration when adding support for more complex algorithms like raid6 p+q (at what point does a 'dma-offload' engine become a 'crypto' engine? at some point they converge) The hope is that other subsystems beyond md could benefit from offload engines. For example, the crc32c calculations in btrfs might be a good candidate, and kcopyd integration has crossed my mind.
Satyam
Dan - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
