Geert Uytterhoeven wrote:
> It's shorter.
>
> Especially `pr_err' fits in the space of `printk', so you don't have to split
> lines that become to long due to adding the KERN_*.
Ah, i see. Thanks for the explanation :-)
Frank
--
To unsubscribe from this list: send the line "unsubscribe linux-cr
Geert Uytterhoeven wrote:
> BTW, why are you using printk(KERN_INFO "..."), and not pr_info("...")?
Without special reason. Is pr_info preferred?
Thanks,
Frank
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More maj
Geert Uytterhoeven wrote:
> On Wed, 25 Feb 2009, Frank Seidel wrote:
> Wel...
>
> Using kmalloc() increases code size, makes the code more complex, and
> increases
> the risk of introducing a memory leak now or later.
Ok, admitted.
>> I just stumbled over tcrypt on th
From: Frank Seidel
Applying kernel janitors todos (printk calls need KERN_*
constants on linebeginnings, reduce stack footprint where
possible) to tcrypts test_hash_speed (where stacks
memory footprint was very high (on i386 1184 bytes to
160 now).
Signed-off-by: Frank Seidel
---
crypto
Geert Uytterhoeven wrote:
> Probably people should be reminded tcrypt can only be a module, not built-in,
> so it won't waste precious unswappable kernel memory if it's static.
Thats right, but it also doesn't hurt to simply use kmalloc, does it? :-)
I just stumbled over tcrypt on the make checkst
Thiago Galesi wrote:
> If you write static char output[1024]; (even inside a function) it's
> not allocated on the stack.
Oh, yes i misunderstood Herbert, sorry. But anyway isn't
it preferred to kmalloc such arrays?
Greg, i thought it was you who told me so, is that right?
Thanks,
Frank
--
To un
From: Frank Seidel
Applying kernel janitors todos (printk calls need KERN_*
constants on linebeginnings, reduce stack footprint where
possible) to tcrypts test_hash_speed (where stacks
memory footprint was very high (on i386 1184 bytes to
164 now).
Signed-off-by: Frank Seidel
---
crypto
Herbert Xu wrote:
>> -char output[1024];
>
> How about just making it static?
Well, it was static before. But there
are efforts to reduce current stack memory
footprints.
Frank
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@v
From: Frank Seidel
Applying kernel janitors todos (printk calls need KERN_*
constants on linebeginnings, reduce stack footprint where
possible) to tcrypts test_hash_speed (where stacks
memory footprint was very high (on i386 1184 bytes to
292 now).
Signed-off-by: Frank Seidel
---
crypto
From: Frank Seidel
According to kerneljanitors todo list all printk calls (beginning
a new line) should have an according KERN_* constant.
Those are the missing pieces here for the crypto subsystem.
Signed-off-by: Frank Seidel
---
crypto/ansi_cprng.c |2 +-
crypto/tcrypt.c | 51
Herbert Xu wrote:
> Please do. If it doesn't have any markings at least we know that
> it needs fixing. If you just add WARNINGs then we lose that
> information.
Thats right, i fully agree. So i'll redo it asap.
Thanks,
Frank
--
To unsubscribe from this list: send the line "unsubscribe linux-cr
Alexey Dobriyan schrieb:
> On Fri, Feb 06, 2009 at 03:19:10PM +0100, Frank Seidel wrote:
>> According to kerneljanitors todo list all printk calls (beginning
>> a new line) should have an according KERN_* constant.
>
> Forget about kernel janitors todo list, fix a bug inste
Alexey Dobriyan schrieb:
> Some messages there were truly debugging and some clearly weren't
> WARNING, but INFO.
Yes, i also thought so, but i didn't venture to change it
to i think it looks like. And as bevor they also were all at
the same (unspecified/default) level...
Do you think its worth/i
From: Frank Seidel
According to kerneljanitors todo list all printk calls (beginning
a new line) should have an according KERN_* constant.
Those are the missing pieces here for the crypto subsystem.
Signed-off-by: Frank Seidel
---
crypto/ansi_cprng.c |2 +-
crypto/tcrypt.c | 48
14 matches
Mail list logo
