On Mon, 2005-02-14 at 10:16 -0800, Andrew Morton wrote:
> Fruhwirth Clemens <[EMAIL PROTECTED]> wrote:
> >
> > First, one has to make kmap fallible.
>
> I think it would be relatively simple and sane to modify the existing
> kmap() implementations to add a new try_kmap() which is atomic and
On Mon, 2005-02-14 at 10:16 -0800, Andrew Morton wrote:
Fruhwirth Clemens [EMAIL PROTECTED] wrote:
First, one has to make kmap fallible.
I think it would be relatively simple and sane to modify the existing
kmap() implementations to add a new try_kmap() which is atomic and returns
Fruhwirth Clemens <[EMAIL PROTECTED]> wrote:
>
> First, one has to make kmap fallible.
I think it would be relatively simple and sane to modify the existing
kmap() implementations to add a new try_kmap() which is atomic and returns
failure if it would have needed to sleep.
That being said,
On Mon, 2005-02-14 at 09:07 -0800, David S. Miller wrote:
> On Mon, 14 Feb 2005 18:06:39 +0100
> Fruhwirth Clemens <[EMAIL PROTECTED]> wrote:
>
> > There is nothing wrong with having special methods, that lack generality
> > but are superior in performance. There is something wrong, when there
>
On Mon, 14 Feb 2005 18:06:39 +0100
Fruhwirth Clemens <[EMAIL PROTECTED]> wrote:
> There is nothing wrong with having special methods, that lack generality
> but are superior in performance. There is something wrong, when there
> are no other. And there are no other for holding three kmappings or
On Mon, 2005-02-14 at 07:56 -0800, David S. Miller wrote:
> On Mon, 14 Feb 2005 14:20:34 +0100
> Fruhwirth Clemens <[EMAIL PROTECTED]> wrote:
>
> > Conclusion: The idea of high-mem and low-mem seperation is fundamentally
> > broken. The limitation of page table entries to a fixed set is causing
>
On Mon, 14 Feb 2005 14:20:34 +0100
Fruhwirth Clemens <[EMAIL PROTECTED]> wrote:
> Conclusion: The idea of high-mem and low-mem seperation is fundamentally
> broken. The limitation of page table entries to a fixed set is causing
> more complications than it solves. Laziness to do things right at
On Thu, 2005-02-10 at 12:54 -0500, James Morris wrote:
> Making a generic N-way scatterlist processor is pointless
> overengineering, causing new problems with non-trivial solutions, for
> no benefit whatsoever.
I respectfully disagree. I spend the last few days thinking about a
solution about
On Thu, 2005-02-10 at 12:54 -0500, James Morris wrote:
Making a generic N-way scatterlist processor is pointless
overengineering, causing new problems with non-trivial solutions, for
no benefit whatsoever.
I respectfully disagree. I spend the last few days thinking about a
solution about
On Mon, 14 Feb 2005 14:20:34 +0100
Fruhwirth Clemens [EMAIL PROTECTED] wrote:
Conclusion: The idea of high-mem and low-mem seperation is fundamentally
broken. The limitation of page table entries to a fixed set is causing
more complications than it solves. Laziness to do things right at memory
On Mon, 2005-02-14 at 07:56 -0800, David S. Miller wrote:
On Mon, 14 Feb 2005 14:20:34 +0100
Fruhwirth Clemens [EMAIL PROTECTED] wrote:
Conclusion: The idea of high-mem and low-mem seperation is fundamentally
broken. The limitation of page table entries to a fixed set is causing
more
On Mon, 14 Feb 2005 18:06:39 +0100
Fruhwirth Clemens [EMAIL PROTECTED] wrote:
There is nothing wrong with having special methods, that lack generality
but are superior in performance. There is something wrong, when there
are no other. And there are no other for holding three kmappings or more
On Mon, 2005-02-14 at 09:07 -0800, David S. Miller wrote:
On Mon, 14 Feb 2005 18:06:39 +0100
Fruhwirth Clemens [EMAIL PROTECTED] wrote:
There is nothing wrong with having special methods, that lack generality
but are superior in performance. There is something wrong, when there
are no
Fruhwirth Clemens [EMAIL PROTECTED] wrote:
First, one has to make kmap fallible.
I think it would be relatively simple and sane to modify the existing
kmap() implementations to add a new try_kmap() which is atomic and returns
failure if it would have needed to sleep.
That being said, kmap() is
On Thu, Feb 10, 2005 at 12:17:24PM +0100, Fruhwirth Clemens wrote:
> On Thu, 2005-02-10 at 02:33 -0800, Andrew Morton wrote:
> > Fruhwirth Clemens <[EMAIL PROTECTED]> wrote:
> > >
> > > On Wed, 2005-02-09 at 17:19 -0800, Andrew Morton wrote:
> > > > Fruhwirth Clemens <[EMAIL PROTECTED]> wrote:
> >
On Thu, Feb 10, 2005 at 12:17:24PM +0100, Fruhwirth Clemens wrote:
On Thu, 2005-02-10 at 02:33 -0800, Andrew Morton wrote:
Fruhwirth Clemens [EMAIL PROTECTED] wrote:
On Wed, 2005-02-09 at 17:19 -0800, Andrew Morton wrote:
Fruhwirth Clemens [EMAIL PROTECTED] wrote:
Adding a few
On Thu, 10 Feb 2005 02:33:44 -0800
Andrew Morton <[EMAIL PROTECTED]> wrote:
> > Is there an easy way to bring pages to lowmem? The cryptoapi is called
> > from the backlog of the networking stack, which is assigned in irq
> > context first and processed softirq context.
>
> Are networking frames
On Thu, 10 Feb 2005, Fruhwirth Clemens wrote:
> Why should I pass the first thing of size X as scatterlist, and the
> second thing of size X as linear buffer?
>
> I could do that. It would be reasonable, because tweaks are more likely
> to be generated than transmitted, read or whatever. But
On Thu, 2005-02-10 at 12:02 -0500, James Morris wrote:
> On Thu, 10 Feb 2005, Fruhwirth Clemens wrote:
>
> > Hm, alright. So I'm going take the internal of kmap_atomic into
> > scatterwalk.c. to test if the page is in highmem, with PageHighMem. If
> > it is, I'm going to kmap_atomic and mark the
On Thu, 10 Feb 2005, Fruhwirth Clemens wrote:
> Hm, alright. So I'm going take the internal of kmap_atomic into
> scatterwalk.c. to test if the page is in highmem, with PageHighMem. If
> it is, I'm going to kmap_atomic and mark the fixmap as used. If it's
> not, I do the "mapping" on my own with
On Thu, 2005-02-10 at 02:33 -0800, Andrew Morton wrote:
> Fruhwirth Clemens <[EMAIL PROTECTED]> wrote:
> >
> > On Wed, 2005-02-09 at 17:19 -0800, Andrew Morton wrote:
> > > Fruhwirth Clemens <[EMAIL PROTECTED]> wrote:
> > > Adding a few more fixmap slots wouldn't hurt anyone. But if you want an
>
Fruhwirth Clemens <[EMAIL PROTECTED]> wrote:
>
> On Wed, 2005-02-09 at 17:19 -0800, Andrew Morton wrote:
> > Fruhwirth Clemens <[EMAIL PROTECTED]> wrote:
> > >
> > > It must be
> > > possible to process more than 2 mappings in softirq context.
> >
> > Adding a few more fixmap slots wouldn't hurt
On Wed, 2005-02-09 at 20:42 -0500, James Morris wrote:
> On Thu, 10 Feb 2005, Fruhwirth Clemens wrote:
>
> > Because a tweak is different from an IV. There can be an arbitrary
> > number of tweaks. For instance, EME takes 1 tweak per 512 bytes. If you
> > have a 4k page to encrypt, you have to
On Wed, 2005-02-09 at 17:19 -0800, Andrew Morton wrote:
> Fruhwirth Clemens <[EMAIL PROTECTED]> wrote:
> >
> > It must be
> > possible to process more than 2 mappings in softirq context.
>
> Adding a few more fixmap slots wouldn't hurt anyone. But if you want an
> arbitrarily large number of
On Wed, 2005-02-09 at 17:19 -0800, Andrew Morton wrote:
Fruhwirth Clemens [EMAIL PROTECTED] wrote:
It must be
possible to process more than 2 mappings in softirq context.
Adding a few more fixmap slots wouldn't hurt anyone. But if you want an
arbitrarily large number of them then no,
On Wed, 2005-02-09 at 20:42 -0500, James Morris wrote:
On Thu, 10 Feb 2005, Fruhwirth Clemens wrote:
Because a tweak is different from an IV. There can be an arbitrary
number of tweaks. For instance, EME takes 1 tweak per 512 bytes. If you
have a 4k page to encrypt, you have to process 8
Fruhwirth Clemens [EMAIL PROTECTED] wrote:
On Wed, 2005-02-09 at 17:19 -0800, Andrew Morton wrote:
Fruhwirth Clemens [EMAIL PROTECTED] wrote:
It must be
possible to process more than 2 mappings in softirq context.
Adding a few more fixmap slots wouldn't hurt anyone. But if you
On Thu, 2005-02-10 at 02:33 -0800, Andrew Morton wrote:
Fruhwirth Clemens [EMAIL PROTECTED] wrote:
On Wed, 2005-02-09 at 17:19 -0800, Andrew Morton wrote:
Fruhwirth Clemens [EMAIL PROTECTED] wrote:
Adding a few more fixmap slots wouldn't hurt anyone. But if you want an
arbitrarily
On Thu, 10 Feb 2005, Fruhwirth Clemens wrote:
Hm, alright. So I'm going take the internal of kmap_atomic into
scatterwalk.c. to test if the page is in highmem, with PageHighMem. If
it is, I'm going to kmap_atomic and mark the fixmap as used. If it's
not, I do the mapping on my own with
On Thu, 2005-02-10 at 12:02 -0500, James Morris wrote:
On Thu, 10 Feb 2005, Fruhwirth Clemens wrote:
Hm, alright. So I'm going take the internal of kmap_atomic into
scatterwalk.c. to test if the page is in highmem, with PageHighMem. If
it is, I'm going to kmap_atomic and mark the fixmap
On Thu, 10 Feb 2005, Fruhwirth Clemens wrote:
Why should I pass the first thing of size X as scatterlist, and the
second thing of size X as linear buffer?
I could do that. It would be reasonable, because tweaks are more likely
to be generated than transmitted, read or whatever. But what
On Thu, 10 Feb 2005 02:33:44 -0800
Andrew Morton [EMAIL PROTECTED] wrote:
Is there an easy way to bring pages to lowmem? The cryptoapi is called
from the backlog of the networking stack, which is assigned in irq
context first and processed softirq context.
Are networking frames ever
On Thu, 10 Feb 2005, Fruhwirth Clemens wrote:
> Because a tweak is different from an IV. There can be an arbitrary
> number of tweaks. For instance, EME takes 1 tweak per 512 bytes. If you
> have a 4k page to encrypt, you have to process 8 tweaks of whatever
> size.
> Therefore, you need 3
Am Mittwoch, den 09.02.2005, 17:19 -0800 schrieb Andrew Morton:
> > It must be
> > possible to process more than 2 mappings in softirq context.
>
> Adding a few more fixmap slots wouldn't hurt anyone. But if you want an
> arbitrarily large number of them then no, we cannot do that.
>
>
Fruhwirth Clemens <[EMAIL PROTECTED]> wrote:
>
> It must be
> possible to process more than 2 mappings in softirq context.
Adding a few more fixmap slots wouldn't hurt anyone. But if you want an
arbitrarily large number of them then no, we cannot do that.
Taking more than one sleeping kmap at
On Wed, 2005-02-09 at 19:30 -0500, James Morris wrote:
> On Wed, 9 Feb 2005, Fruhwirth Clemens wrote:
>
> > I can't code for the case of two. Because, first, that's the idea of
> > generic in the name "generic scatterwalk", second, I need at least 3
> > scatterlists in parallel for LRW.
>
> Can
On Wed, 9 Feb 2005, Fruhwirth Clemens wrote:
> I can't code for the case of two. Because, first, that's the idea of
> generic in the name "generic scatterwalk", second, I need at least 3
> scatterlists in parallel for LRW.
Can you explain why you need a third scatterlist for the LRW tweak?
My
On Tue, 2005-02-08 at 19:09 -0500, James Morris wrote:
> On Wed, 9 Feb 2005, Fruhwirth Clemens wrote:
>
> > > You can't call kmap() in softirq context (why was it even trying?):
> >
> > Why not? What's the alternative, then?
>
> It can sleep in map_new_virtual().
>
> The alternative is to use
On Tue, 2005-02-08 at 19:09 -0500, James Morris wrote:
On Wed, 9 Feb 2005, Fruhwirth Clemens wrote:
You can't call kmap() in softirq context (why was it even trying?):
Why not? What's the alternative, then?
It can sleep in map_new_virtual().
The alternative is to use atomic kmaps.
On Wed, 9 Feb 2005, Fruhwirth Clemens wrote:
I can't code for the case of two. Because, first, that's the idea of
generic in the name generic scatterwalk, second, I need at least 3
scatterlists in parallel for LRW.
Can you explain why you need a third scatterlist for the LRW tweak?
My
On Wed, 2005-02-09 at 19:30 -0500, James Morris wrote:
On Wed, 9 Feb 2005, Fruhwirth Clemens wrote:
I can't code for the case of two. Because, first, that's the idea of
generic in the name generic scatterwalk, second, I need at least 3
scatterlists in parallel for LRW.
Can you explain
Fruhwirth Clemens [EMAIL PROTECTED] wrote:
It must be
possible to process more than 2 mappings in softirq context.
Adding a few more fixmap slots wouldn't hurt anyone. But if you want an
arbitrarily large number of them then no, we cannot do that.
Taking more than one sleeping kmap at a
Am Mittwoch, den 09.02.2005, 17:19 -0800 schrieb Andrew Morton:
It must be
possible to process more than 2 mappings in softirq context.
Adding a few more fixmap slots wouldn't hurt anyone. But if you want an
arbitrarily large number of them then no, we cannot do that.
Possibly one
On Thu, 10 Feb 2005, Fruhwirth Clemens wrote:
Because a tweak is different from an IV. There can be an arbitrary
number of tweaks. For instance, EME takes 1 tweak per 512 bytes. If you
have a 4k page to encrypt, you have to process 8 tweaks of whatever
size.
Therefore, you need 3
On Wed, 9 Feb 2005, Fruhwirth Clemens wrote:
> > You can't call kmap() in softirq context (why was it even trying?):
>
> Why not? What's the alternative, then?
It can sleep in map_new_virtual().
The alternative is to use atomic kmaps. For this code, unless you can
point to something concrete
On Tue, 2005-02-08 at 18:30 -0500, James Morris wrote:
> On Tue, 8 Feb 2005, Fruhwirth Clemens wrote:
>
> > I shot out the last patch too quickly. Having reviewed the mapping one
> > more time I noticed, that there as the possibility of "off-by-one"
> > unmapping, and instead of doing doubtful
On Tue, 8 Feb 2005, Fruhwirth Clemens wrote:
> I shot out the last patch too quickly. Having reviewed the mapping one
> more time I noticed, that there as the possibility of "off-by-one"
> unmapping, and instead of doing doubtful guesses, if that's the case, I
> added a base pointer to
On Tue, 2005-02-08 at 17:08 +0100, Fruhwirth Clemens wrote:
> On Tue, 2005-02-08 at 09:48 -0500, James Morris wrote:
> > On Sat, 5 Feb 2005, Fruhwirth Clemens wrote:
> >
> > > + * The generic scatterwalker applies a certain function, pf, utilising
> > > + * an arbitrary number of scatterlist data
On Tue, 2005-02-08 at 09:48 -0500, James Morris wrote:
> On Sat, 5 Feb 2005, Fruhwirth Clemens wrote:
>
> > + * The generic scatterwalker applies a certain function, pf, utilising
> > + * an arbitrary number of scatterlist data as it's arguments. These
> > + * arguments are supplied as an array of
On Sat, 5 Feb 2005, Fruhwirth Clemens wrote:
> Fixed formating and white-spaces. The biggest change is, that I stripped
> a redundant check from scatterwalk.c. This omission seems justified and
> shows no regression on my system. ( http://lkml.org/lkml/2005/2/3/87 )
> Can you give it a quick test
On Thu, 3 Feb 2005, Fruhwirth Clemens wrote:
> First attempt:
>
> static inline int scatterwalk_needscratch(struct scatter_walk *walk, int
> nbytes) {
>return ((nbytes) <= (walk)->len_this_page &&
>(((unsigned long)(walk)->data) & (PAGE_CACHE_SIZE - 1)) +
> (nbytes) <=
On Thu, 3 Feb 2005, Fruhwirth Clemens wrote:
First attempt:
static inline int scatterwalk_needscratch(struct scatter_walk *walk, int
nbytes) {
return ((nbytes) = (walk)-len_this_page
(((unsigned long)(walk)-data) (PAGE_CACHE_SIZE - 1)) +
(nbytes) =
On Sat, 5 Feb 2005, Fruhwirth Clemens wrote:
Fixed formating and white-spaces. The biggest change is, that I stripped
a redundant check from scatterwalk.c. This omission seems justified and
shows no regression on my system. ( http://lkml.org/lkml/2005/2/3/87 )
Can you give it a quick test
On Tue, 2005-02-08 at 09:48 -0500, James Morris wrote:
On Sat, 5 Feb 2005, Fruhwirth Clemens wrote:
+ * The generic scatterwalker applies a certain function, pf, utilising
+ * an arbitrary number of scatterlist data as it's arguments. These
+ * arguments are supplied as an array of
On Tue, 2005-02-08 at 17:08 +0100, Fruhwirth Clemens wrote:
On Tue, 2005-02-08 at 09:48 -0500, James Morris wrote:
On Sat, 5 Feb 2005, Fruhwirth Clemens wrote:
+ * The generic scatterwalker applies a certain function, pf, utilising
+ * an arbitrary number of scatterlist data as it's
On Tue, 8 Feb 2005, Fruhwirth Clemens wrote:
I shot out the last patch too quickly. Having reviewed the mapping one
more time I noticed, that there as the possibility of off-by-one
unmapping, and instead of doing doubtful guesses, if that's the case, I
added a base pointer to scatter_walk,
On Tue, 2005-02-08 at 18:30 -0500, James Morris wrote:
On Tue, 8 Feb 2005, Fruhwirth Clemens wrote:
I shot out the last patch too quickly. Having reviewed the mapping one
more time I noticed, that there as the possibility of off-by-one
unmapping, and instead of doing doubtful guesses, if
On Wed, 9 Feb 2005, Fruhwirth Clemens wrote:
You can't call kmap() in softirq context (why was it even trying?):
Why not? What's the alternative, then?
It can sleep in map_new_virtual().
The alternative is to use atomic kmaps. For this code, unless you can
point to something concrete in
On Wed, 2005-02-02 at 17:46 -0500, James Morris wrote:
> This code tests ok with IPSec, and delivers some good performance
> improvements. e.g. FTP transfers over transport mode AES over GigE sped
> up with this patch applied on one side of the connection by 20% for send
> and 15% for receive.
>
On Wed, 2005-02-02 at 17:46 -0500, James Morris wrote:
This code tests ok with IPSec, and delivers some good performance
improvements. e.g. FTP transfers over transport mode AES over GigE sped
up with this patch applied on one side of the connection by 20% for send
and 15% for receive.
On Wed, 2005-02-02 at 17:46 -0500, James Morris wrote:
> On Sun, 30 Jan 2005, Fruhwirth Clemens wrote:
> > +#define scatterwalk_needscratch(walk, nbytes)
> > \
> > + ((nbytes) <= (walk)->len_this_page &&
> >
On Thu, 2005-02-03 at 13:40 +1300, Michal Ludvig wrote:
> Fruhwirth Clemens wrote:
>
> > Especially, if James ask me to redo Michal's conflicting patches
> > (done btw), which are totally off-topic for me.
>
> Great, thanks! Has the interface for multiblock modules changed or
> should my old
On Thu, 2005-02-03 at 13:40 +1300, Michal Ludvig wrote:
Fruhwirth Clemens wrote:
Especially, if James ask me to redo Michal's conflicting patches
(done btw), which are totally off-topic for me.
Great, thanks! Has the interface for multiblock modules changed or
should my old modules
On Wed, 2005-02-02 at 17:46 -0500, James Morris wrote:
On Sun, 30 Jan 2005, Fruhwirth Clemens wrote:
+#define scatterwalk_needscratch(walk, nbytes)
\
+ ((nbytes) = (walk)-len_this_page
\
+
Fruhwirth Clemens wrote:
> Especially, if James ask me to redo Michal's conflicting patches
> (done btw), which are totally off-topic for me.
Great, thanks! Has the interface for multiblock modules changed or
should my old modules work with it with no more effort?
Unfortulately I don't have a
On Thu, 03 Feb 2005 01:21:35 +0100
Fruhwirth Clemens <[EMAIL PROTECTED]> wrote:
> I'm afraid, I'm not going to change it. I already lost too much time
> pushing LRW into the kernel.
The work has to be done by somebody. Linus would certainly reject any
attempt I would make to push code with that
On Wed, 2 Feb 2005, James Morris wrote:
> Correct, although I think this will get lost in the noise given that it's
> sitting in the middle of crypto processing. I'd remove it.
Dave just ok'd it, so take his advice over mine :-)
- james
--
James Morris
<[EMAIL PROTECTED]>
-
To unsubscribe
On Wed, 2005-02-02 at 15:34 -0800, David S. Miller wrote:
> Also, I think there will be objections to that studlyCaps naming you
> said your other code has. Keep garbage like that in the x11 sources,
> if you don't mind :-)
I'm afraid, I'm not going to change it. I already lost too much time
On Thu, 3 Feb 2005, Fruhwirth Clemens wrote:
> > > +static int ecb_process_gw(void *_priv, int nsg, void **buf)
>
> > What does _gw mean?
>
> generic walker.. can be removed, if you like.
That's fine, was just wondering.
> > > + r = pf(priv, nsl, dispatch_list);
> > > +
On Thu, 03 Feb 2005 00:28:29 +0100
Fruhwirth Clemens <[EMAIL PROTECTED]> wrote:
> I suspected unlikely to be a hint for the compiler to do better jump
> prediction and speculations. Remove?
I don't think it hurts, keep it in there.
When the final patch is made with James's requested fixups,
On Wed, 2005-02-02 at 17:46 -0500, James Morris wrote:
> On Sun, 30 Jan 2005, Fruhwirth Clemens wrote:
> > James, please test it against ipsec. I'm confident, that everything will
> > work as expected and we can proceed to merge padlock-multiblock against this
> > scatterwalker, so please Andrew,
On Mon, 24 Jan 2005, Fruhwirth Clemens wrote:
> This patch adds the ability for a cipher mode to store cipher mode specific
> information in crypto_tfm. This is necessary for LRW's precomputed
> GF-multiplication tables.
This one looks fine as part of the LRW patchset (i.e. not needed for
On Sun, 30 Jan 2005, Fruhwirth Clemens wrote:
> Ok, here comes a reworked scatterwalk patch. Instead of making
> scatterwalk_walk controllable via another additional function or interface,
> I decided to make scatterwalk_walk quickly restartable. Therefore, I had to
> move an initialization
On Sun, 30 Jan 2005, Fruhwirth Clemens wrote:
Ok, here comes a reworked scatterwalk patch. Instead of making
scatterwalk_walk controllable via another additional function or interface,
I decided to make scatterwalk_walk quickly restartable. Therefore, I had to
move an initialization
On Mon, 24 Jan 2005, Fruhwirth Clemens wrote:
This patch adds the ability for a cipher mode to store cipher mode specific
information in crypto_tfm. This is necessary for LRW's precomputed
GF-multiplication tables.
This one looks fine as part of the LRW patchset (i.e. not needed for
generic
On Wed, 2005-02-02 at 17:46 -0500, James Morris wrote:
On Sun, 30 Jan 2005, Fruhwirth Clemens wrote:
James, please test it against ipsec. I'm confident, that everything will
work as expected and we can proceed to merge padlock-multiblock against this
scatterwalker, so please Andrew, merge
On Thu, 03 Feb 2005 00:28:29 +0100
Fruhwirth Clemens [EMAIL PROTECTED] wrote:
I suspected unlikely to be a hint for the compiler to do better jump
prediction and speculations. Remove?
I don't think it hurts, keep it in there.
When the final patch is made with James's requested fixups, I'll
On Thu, 3 Feb 2005, Fruhwirth Clemens wrote:
+static int ecb_process_gw(void *_priv, int nsg, void **buf)
What does _gw mean?
generic walker.. can be removed, if you like.
That's fine, was just wondering.
+ r = pf(priv, nsl, dispatch_list);
+ if(unlikely(r 0))
On Wed, 2005-02-02 at 15:34 -0800, David S. Miller wrote:
Also, I think there will be objections to that studlyCaps naming you
said your other code has. Keep garbage like that in the x11 sources,
if you don't mind :-)
I'm afraid, I'm not going to change it. I already lost too much time
On Wed, 2 Feb 2005, James Morris wrote:
Correct, although I think this will get lost in the noise given that it's
sitting in the middle of crypto processing. I'd remove it.
Dave just ok'd it, so take his advice over mine :-)
- james
--
James Morris
[EMAIL PROTECTED]
-
To unsubscribe
On Thu, 03 Feb 2005 01:21:35 +0100
Fruhwirth Clemens [EMAIL PROTECTED] wrote:
I'm afraid, I'm not going to change it. I already lost too much time
pushing LRW into the kernel.
The work has to be done by somebody. Linus would certainly reject any
attempt I would make to push code with that
Fruhwirth Clemens wrote:
Especially, if James ask me to redo Michal's conflicting patches
(done btw), which are totally off-topic for me.
Great, thanks! Has the interface for multiblock modules changed or
should my old modules work with it with no more effort?
Unfortulately I don't have a
On Sat, Jan 29, 2005 at 10:23:10AM -0800, Andrew Morton wrote:
> Fruhwirth Clemens <[EMAIL PROTECTED]> wrote:
> >
> > My advise is, drop Michaels patches
> > for now, merge scatterwalker and add an ability to change the stepsize
> > dynamically in the run. Then I will finish my port and post it.
Fruhwirth Clemens <[EMAIL PROTECTED]> wrote:
>
> My advise is, drop Michaels patches
> for now, merge scatterwalker and add an ability to change the stepsize
> dynamically in the run. Then I will finish my port and post it.
>
> If we can agree on this "agenda", I'll shift my focus to
On Tue, 2005-01-25 at 10:52 -0500, James Morris wrote:
> On Mon, 24 Jan 2005, Andrew Morton wrote:
>
> > These patches clash badly with Michael Ludvig's work:
> >
> >
On Tue, 2005-01-25 at 10:52 -0500, James Morris wrote:
On Mon, 24 Jan 2005, Andrew Morton wrote:
These patches clash badly with Michael Ludvig's work:
Fruhwirth Clemens [EMAIL PROTECTED] wrote:
My advise is, drop Michaels patches
for now, merge scatterwalker and add an ability to change the stepsize
dynamically in the run. Then I will finish my port and post it.
If we can agree on this agenda, I'll shift my focus to scatterwalker
On Tue, 25 Jan 2005, Fruhwirth Clemens wrote:
> The changes, I purposed, shouldn't be too hard to implement. I will
> build a skeleton for Michael, but I can't test the code, as I don't own
> a padlock system, further
I've got one now, and can use it for testing.
> I'm sorry to say but, my time
On Tue, 2005-01-25 at 10:52 -0500, James Morris wrote:
> I think the generic scatterwalk changes are more important and
> fundamental (still to be fully reviewed).
>
> I agree with Fruhwirth that the cipher code is starting to become
> ungainly. I'm not sure these patches are heading in the
On Mon, 24 Jan 2005, Andrew Morton wrote:
> These patches clash badly with Michael Ludvig's work:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc2/2.6.11-rc2-mm1/broken-out/cryptoapi-prepare-for-processing-multiple-buffers-at.patch
>
On Mon, 24 Jan 2005, Andrew Morton wrote:
These patches clash badly with Michael Ludvig's work:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc2/2.6.11-rc2-mm1/broken-out/cryptoapi-prepare-for-processing-multiple-buffers-at.patch
On Tue, 2005-01-25 at 10:52 -0500, James Morris wrote:
I think the generic scatterwalk changes are more important and
fundamental (still to be fully reviewed).
I agree with Fruhwirth that the cipher code is starting to become
ungainly. I'm not sure these patches are heading in the right
On Tue, 25 Jan 2005, Fruhwirth Clemens wrote:
The changes, I purposed, shouldn't be too hard to implement. I will
build a skeleton for Michael, but I can't test the code, as I don't own
a padlock system, further
I've got one now, and can use it for testing.
I'm sorry to say but, my time is
On Mon, 2005-01-24 at 14:31 -0800, Andrew Morton wrote:
> Fruhwirth Clemens <[EMAIL PROTECTED]> wrote:
> >
> > This patch adds the ability for a cipher mode to store cipher mode specific
> > information in crypto_tfm. This is necessary for LRW's precomputed
> > GF-multiplication tables.
>
> These
Fruhwirth Clemens <[EMAIL PROTECTED]> wrote:
>
> This patch adds the ability for a cipher mode to store cipher mode specific
> information in crypto_tfm. This is necessary for LRW's precomputed
> GF-multiplication tables.
These patches clash badly with Michael Ludvig's work:
I'll review this in detail over the next day or so (still catching up on
some backlog after vacation).
Just wondering how much testing the generic scatterwalk code has had (I
gather disk encryption has been tested, but what about ipsec?).
- James
--
James Morris
<[EMAIL PROTECTED]>
-
To
This patch adds the ability for a cipher mode to store cipher mode specific
information in crypto_tfm. This is necessary for LRW's precomputed
GF-multiplication tables.
Signed-off-by: Fruhwirth Clemens <[EMAIL PROTECTED]>
--- 0/crypto/api.c 2005-01-20 10:15:22.0 +0100
+++
Fruhwirth Clemens [EMAIL PROTECTED] wrote:
This patch adds the ability for a cipher mode to store cipher mode specific
information in crypto_tfm. This is necessary for LRW's precomputed
GF-multiplication tables.
These patches clash badly with Michael Ludvig's work:
On Mon, 2005-01-24 at 14:31 -0800, Andrew Morton wrote:
Fruhwirth Clemens [EMAIL PROTECTED] wrote:
This patch adds the ability for a cipher mode to store cipher mode specific
information in crypto_tfm. This is necessary for LRW's precomputed
GF-multiplication tables.
These patches
This patch adds the ability for a cipher mode to store cipher mode specific
information in crypto_tfm. This is necessary for LRW's precomputed
GF-multiplication tables.
Signed-off-by: Fruhwirth Clemens [EMAIL PROTECTED]
--- 0/crypto/api.c 2005-01-20 10:15:22.0 +0100
+++
1 - 100 of 101 matches
Mail list logo
