> > You'll note that loop.c goes from (page/offset/len) to (addr/len),
> > and this transfer function then immediately goes from (addr,len)
> > to (page/offset/len). That's rather silly ..
> Changing that would kill all existing modules that use the loop device.
That's OK - if they don't want to properly adapt to the new API they can
just kmap the page and call into the old-style code. A five-line wrapper.
> Maybe nobody cares. Then we can do so in a subsequent patch.
Splitting these changes into two almost doubles the testing effort, or
halves the coverage. We really should aim to get both these changes in
place at the same time. I know that I wouldn't bother testing it if there
are more large changes pending...
Could we pleeeze have a little cryptoloop.txt which just gives the basics
on where to obtain the tools and how to get the thing up and running? It's
a right pain having to go scrabbling all over the internet working out how
to set stuff up if you just want to do a bit of testing every few months.
(Where are the first and second patches btw? Merged? Is a fourth
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jul 07 2003 - 22:00:17 EST