Wednesday, October 17, 2012

%.*s - Weird printk or Format of the format string

See this patch: https://lkml.org/lkml/2012/8/21/46

The author suggests:

- p9_debug(P9_DEBUG_VFS, "%s -> %s (%s)\n",
- dentry->d_name.name, st->extension, buffer);
+ p9_debug(P9_DEBUG_VFS, "%s -> %s (%.*s)\n",
+ dentry->d_name.name, st->extension, buflen, buffer);

But what the heck does %.*s? And why buflen variable was added as parameter to p9_debug? What would be the output of the C program above:

#include <stdio.h>

void main () {
        int i;
        char *ab ="abcdefghi";

        for (i = 0; i < 10; i++)
                printf ("%.*s\n", i, ab);
}

[peter@ace tmp]$ gcc test.c;./a.out

a
ab
abc
abcd
abcde
abcdef
abcdefg
abcdefgh
abcdefghi

Cool huh?

Sunday, October 14, 2012

Almost in the top ten

Thanks to my internship, on the raking of the number of patches accepted, only 10 people had sent more patches than me for the Kernel 3.7:

The ranking: http://www.remword.com/kps_result/3.7_petop.html

\o/

Not bad for a newbie.

Thursday, October 11, 2012

More than 100 (2) \o/


[peter@ace linux-next]$ git log |grep Author |grep peter.senna@gmail.com |wc -l
106

More than 100 patches accepted in the Linux Kernel. I'm happy with it but...

Those are really simple patches and I need to work on finding more complex things to do. But I think I'm on the way...

Friday, October 5, 2012

It is not enough to fix a bug and describe it correctly...

I'm sending a lot of patches. Many are just being accepted. But there is one very interesting rejection. I have not received nack, and the patch was not directed to /dev/null. The maintainers are happy with the code, but they "really" want me to do a very specific commit message.

Monday, October 1, 2012

How to write commit messages?


From: Linus Torvalds <torvalds@linux-foundation.org>
Newsgroups: fa.linux.kernel
Subject: Re: [PATCH] Bugfix to commit
Date: Tue, 23 Oct 2007 15:53:41 UTC
Message-ID: <fa.kLlZ0+PrvWCrpZjNV34+zBLE2ro@ifi.uio.no>

On Tue, 23 Oct 2007, Olaf Hering wrote:
>
> On Mon, Oct 22, Grant Likely wrote:
>
> > Olaf, do I have the correct solution here?
>
> Sure.

Side note: I already applied that patch, but take a look at the commit
message.

That's right: I had to edit the message provided to make it readable. So
I'll just take this opportunity to ask people that when they send
bug-fixes, please try to make the subject line and message make sense for
a *reader*, not for yourself (or even to me, although if it's readable to
some generic person, it's hopefully readable to me too!).

So a subject line of "Bugfix to commit <commit-sha-goes-here>" is
obviously not a very nice one, if you're looking at the kernel commit
history in gitk or some other visualizer that shows the first line as the
subject for the whole commit. It just doesn't make any sense to the
reader!

Related to that, another thing that also happens is that people write
subject lines (and the description) as if everybody realized that
something is particular to that architecture or driver. It may be true
that that particular developer (or development list) is only about ppc,
and then people write subject lines like "Fix execve() argument handling",
but again, when a *generic* person reads that, it now reads totally wrong,
since it wasn't execve() in general, it was a particular architecture that
it went wrong for.

So the rule should be:

 - if it's not fairly generic, specify the area (architecture, subsystem,
   driver) that the fix is for in the subject line. Even if you end up
   initially sending the fix out to just a list that handles that
   particular subsystem anyway.

 - don't use commit names in the subject line - and while it's great to
   use them in the body of the explanation, even there you don't want to
   assume that people read it from within git. People see patches and
   commit changelogs on the web or the commit mailing lists, so when
   specifying an exact version, also specify the human-readable name of
   that version.

 - write the commit message for an outsider, and use whitespace. The
   third-most common fixup I end up doing (after the above two) is to
   split things up into shorter paragraphs, after somebody wrote a good
   changelog entry, but made it one large unreadable blob of text. The
   more involved and technical some description is (and that's what long
   changelog entries should be - we don't want a fluffy novella here!),
   the more "breather space" and individually understandable small
   snippets of text readers need. Making things too dense is bad.

Anyway, this was in no way meant to be a specific problem for Grant or
Olaf - I end up editing just about half of all the commit messages of
stuff I get in email (except for Andrew's stuff, since Andrew largely does
the same kinds of cleanups anyway, so I only need to edit up a small
percentage of the patches he forwards). I'd like it to be *much* less than
that, so I thought I should speak up since I had an example of this.

Linus

Source: http://yarchive.net/comp/linux/commit_messages.html