Signed-off-by: Richard Hartmann <[email protected]>
---
crypto/proc.c | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/crypto/proc.c b/crypto/proc.c
index 58fef67..56a3c64 100644
--- a/crypto/proc.c
+++ b/crypto/proc.c
@@ -8,7 +8,7 @@
*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License as published by the Free
- * Software Foundation; either version 2 of the License, or (at your option)
+ * Software Foundation; either version 2 of the License, or (at your option)
* any later version.
*
*/
@@ -79,15 +79,15 @@ static void c_stop(struct seq_file *m, void *p)
static int c_show(struct seq_file *m, void *p)
{
struct crypto_alg *alg = list_entry(p, struct crypto_alg, cra_list);
-
+
seq_printf(m, "name : %s\n", alg->cra_name);
seq_printf(m, "driver : %s\n", alg->cra_driver_name);
seq_printf(m, "module : %s\n", module_name(alg->cra_module));
seq_printf(m, "priority : %d\n", alg->cra_priority);
seq_printf(m, "refcnt : %d\n", atomic_read(&alg->cra_refcnt));
seq_printf(m, "selftest : %s\n",
- (alg->cra_flags & CRYPTO_ALG_TESTED) ?
- "passed" : "unknown");
+ (alg->cra_flags & CRYPTO_ALG_TESTED) ?
+ "passed" : "unknown");
if (alg->cra_flags & CRYPTO_ALG_LARVAL) {
seq_printf(m, "type : larval\n");
@@ -99,7 +99,7 @@ static int c_show(struct seq_file *m, void *p)
alg->cra_type->show(m, alg);
goto out;
}
-
+
switch (alg->cra_flags & (CRYPTO_ALG_TYPE_MASK | CRYPTO_ALG_LARVAL)) {
case CRYPTO_ALG_TYPE_CIPHER:
seq_printf(m, "type : cipher\n");
@@ -133,7 +133,7 @@ static int crypto_info_open(struct inode *inode, struct file *file)
{
return seq_open(file, &crypto_seq_ops);
}
-
+
static const struct file_operations proc_crypto_ops = {
.open = crypto_info_open,
.read = seq_read,
--
1.6.6.1
Richard Hartmann <[email protected]> writes:
> seq_printf(m, "name : %s\n", alg->cra_name);
> seq_printf(m, "driver : %s\n", alg->cra_driver_name);
> seq_printf(m, "module : %s\n", module_name(alg->cra_module));
> seq_printf(m, "priority : %d\n", alg->cra_priority);
> seq_printf(m, "refcnt : %d\n", atomic_read(&alg->cra_refcnt));
> seq_printf(m, "selftest : %s\n",
> - (alg->cra_flags & CRYPTO_ALG_TESTED) ?
> - "passed" : "unknown");
> + (alg->cra_flags & CRYPTO_ALG_TESTED) ?
> + "passed" : "unknown");
Why did you replaced a tab with spaces here??
Eric
On Fri, Feb 19, 2010 at 02:48, Eric W. Biederman <[email protected]> wrote:
> Why did you replaced a tab with spaces here??
The first tab is indentation, displaying the logical nesting level.
The second tab including the whitespaces after it was formatting.
Although the official tab width in the linux kernel is 8 chars, not
all code adheres to this rule. Maintaining a clear separation between
indentation and formatting, i.e. using tabs as initially intended, helps
to keep everyone happy, no matter what tab width they use.
If this change is actually controversial, I have no problem removing
this part from the patch. However, it is my _strong_ feeling, that it is
beneficial to keep it.
If there is any wider interest in this topic, I am more than willing to
take this up on the main list in a separate thread. Unless it has
already been discussed, of course.
Thanks for looking at the patch,
Richard
On Fri, Feb 19, 2010 at 11:10:47AM +0100, Richard Hartmann wrote:
>
> If this change is actually controversial, I have no problem removing
> this part from the patch. However, it is my _strong_ feeling, that it is
> beneficial to keep it.
FWIW I don't like this change so I'm dropping it.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On Fri, Feb 19, 2010 at 13:17, Herbert Xu <[email protected]> wrote:
> FWIW I don't like this change so I'm dropping it.
Dropping the change or the whole patch? I.e. should I resubmit
without that part?
Richard
On Fri, Feb 19, 2010 at 05:35:35PM +0100, Richard Hartmann wrote:
> On Fri, Feb 19, 2010 at 13:17, Herbert Xu <[email protected]> wrote:
>
> > FWIW I don't like this change so I'm dropping it.
>
> Dropping the change or the whole patch? I.e. should I resubmit
> without that part?
I'm just dropping this particular change. If there are any
other ones where you've done a similar thing, then please either
revise or drop those.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On Sat, Feb 20, 2010 at 01:46, Herbert Xu <[email protected]> wrote:
> I'm just dropping this particular change. If there are any
> other ones where you've done a similar thing, then please either
> revise or drop those.
In this case, please hold seed, tcrypt, wp512 & xcbc. I will
refactor them.
The last batch of patches did not have any of these changes.
Thanks,
Richard
On Sat, Feb 20, 2010 at 02:59:44AM +0100, Richard Hartmann wrote:
>
> In this case, please hold seed, tcrypt, wp512 & xcbc. I will
> refactor them.
OK.
> The last batch of patches did not have any of these changes.
Thanks for checking.
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On Sat, Feb 20, 2010 at 03:48, Herbert Xu <[email protected]> wrote:
>> In this case, please hold seed, tcrypt, wp512 & xcbc. I will
>> refactor them.
>
> OK.
Another workflow question:
Does LKML as a whole prefer rebased patches, patches on top of the
old one or does not one care as long as it's clear what to apply in what
order?
Or does everyone have a different opionion, in which case: What is
yours?
> Thanks for checking.
No need to thank me. You decide what goes in and I accept that.
I signed up to weworking stuff until it suits the relevant maintainer
before I cloned the repo.
Richard
On Sat, Feb 20, 2010 at 11:26:46AM +0100, Richard Hartmann wrote:
>
> Another workflow question:
> Does LKML as a whole prefer rebased patches, patches on top of the
> old one or does not one care as long as it's clear what to apply in what
> order?
> Or does everyone have a different opionion, in which case: What is
> yours?
It depends on what you're working on. For this case in particular,
sending the missing bits instead of the whole thing is my preferred
solution.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt