--- On Wed, 8/27/08, Andi Kleen <andi@firstfloor.org> wrote:
Cryptoloop? No, my code isn't the 'same' as loop.c and hence can't provide for cryptoloop. I lose, you win :)
Cryptoloop was designed so b'coz 'loop' feature was available, not the other way round. Had we not had '-o loop', developers would have devised mechanism for encrypting block devices rather than exploiting the -o loop hack. In retrospect, it seems Cryptoloop was a bad design based upon a hack.
Encryption? Yes, my code does provide a way for it. It supports better dm-crypt/LUKS off the shelf.
Loop.c sure provides more 'features' but the point is that we can make do without them, which only adds to the complexity. A simpler and more generic driver could do us equal good.
I see one mail from Andrew Morton suggesting removal of cryptoloop altogether in order to ramp up its obsoletion! I am only providing a more-transparent-way of using dm-crypt.
I assume the concede Kasper's point on 'offset' feature of loop.c.
Anyways, seems we are moving from discussion to debate. You've got the whole picture and now its purely your call to approve of it or not.
Better still, you could suggest how to make it better: we are for sure gonna drop cryptoloop for dm-crypt. What wud we do with the then-unnecessary crypt support of loop.c?
Or maybe, for the time being, it would be better to modify Loop.c to allow for runtime alloc/free of as many resources as needed and provide for sysfs interface to add/remove 'loop' rather than ioctls?
I had an idea and i cooked up a code. I wanted to put it somewhere for someone to stumble upon the idea sometime. I am done.
Best Regards,
-Jassi
--
