Am Mo, den 01.03.2004 schrieb Bartlomiej Zolnierkiewicz um 01:47:
> http://www.kernel.org/pub/linux/kernel/people/bart/dm-byteswap-2.6.4-rc1.patch
>
> Guess what's this? :)
The thieves... they've stolen my precioussss. ;)
> It is simply a stripped down dm-crypt.c, so all credits go to Christophe.
> I have tested it quickly with loop device and it seems to work.
Yes, it's not that complicated. Looks good.
BTW: You don't need the km_types voodoo as the conversion routine is
never called from a softirq context and you are allowed (but should try
to avoid it) to sleep. You could add a conditional reschedule after
kunmapping the buffers to keep the latency low on non-preempt kernels.
BTW: I've got some cleanups and a small fix in Andrew's latest tree
(using a #define for the log prefix and I bvec array thingy).
On Monday 01 of March 2004 14:23, Christophe Saout wrote:
> Am Mo, den 01.03.2004 schrieb Bartlomiej Zolnierkiewicz um 01:47:
> > http://www.kernel.org/pub/linux/kernel/people/bart/dm-byteswap-2.6.4-rc1.
> >patch
> >
> > Guess what's this? :)
>
> The thieves... they've stolen my precioussss. ;)
>
> > It is simply a stripped down dm-crypt.c, so all credits go to Christophe.
> > I have tested it quickly with loop device and it seems to work.
>
> Yes, it's not that complicated. Looks good.
> BTW: You don't need the km_types voodoo as the conversion routine is
> never called from a softirq context and you are allowed (but should try
> to avoid it) to sleep. You could add a conditional reschedule after
> kunmapping the buffers to keep the latency low on non-preempt kernels.
Yes, you are of course right. I will remove "km_types voodoo".
> BTW: I've got some cleanups and a small fix in Andrew's latest tree
> (using a #define for the log prefix and I bvec array thingy).
Yep, I've seen them already.
Thanks,
Bartlomiej