linux-kernel - Re: [PATCH v4] x86, olpc: add debugfs interface for EC commands

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 27 Mar 2012 01:49:47 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Daniel Drake <dsd@...top.org>, mingo@...hat.com,
	tglx@...utronix.de, hpa@...or.com, x86@...nel.org,
	linux-kernel@...r.kernel.org, dilinger@...ued.net, pgf@...top.org,
	Joe Perches <joe@...ches.com>
Subject: Re: [PATCH v4] x86, olpc: add debugfs interface for EC commands


* Andrew Morton <akpm@...ux-foundation.org> wrote:

> On Tue, 27 Mar 2012 01:14:08 +0200
> Ingo Molnar <mingo@...nel.org> wrote:
> 
> > 
> > * Andrew Morton <akpm@...ux-foundation.org> wrote:
> > 
> > > > Signed-off-by: Daniel Drake <dsd@...top.org>
> > > > Originally-from: Paul Fox <pgf@...top.org>
> > > > Cc: Ingo Molnar <mingo@...e.hu>
> > > > Cc: Thomas Gleixner <tglx@...utronix.de>
> > > > Cc: "H. Peter Anvin" <hpa@...or.com>
> > > > Cc: Andres Salomon <dilinger@...ued.net>
> > > > 
> > > > ...
> > > >
> > > > v4: really fix sign-off tags
> > > 
> > > s/fix/break/?  "Originally-from" is not a recognised tag.  If this code
> > > is based upon an earlier version from Paul then Signed-off-by: is
> > > correct.
> > 
> > No, the original ordering was *not* correct:
> > 
> >   From: Daniel Drake <dsd@...top.org>
> > 
> >   [...]
> > 
> >   Signed-off-by: Daniel Drake <dsd@...top.org>
> >   Signed-off-by: Paul Fox <pgf@...top.org>
> > 
> > In the previous discussion we had I explained what the rules for 
> > signoffs are. Let me quote Linus as well:
> > 
> >   " The sign-off chain should be very simple: the first person 
> >     to sign off should be the author, and the last person to 
> >     sign off should be the committer. "
> > 
> >   https://lkml.org/lkml/2012/3/22/489
> >   
> > This is not true for this patch, because the first signoff does 
> > not match the 'From:' line (author).
> > 
> > Nor is the last signoff the committer - i.e. the person sending 
> > me this patch to apply. Every maintainer along the route adds a 
> > signoff to the tail if it's propagated via email, or does a 
> > merge commit if it's a pull.
> > 
> > If Daniel sends me a patch he should be the last signoff. If he 
> > authored the patch then he should also be the first (and, by 
> > implication, only) signoff. Signed-off-by does not recognize 
> > multiple authorship - that has to be written into the changelog, 
> > added via another type of tag - either approach is fine to me. 
> 
> That's a bunch of stuff which you and Linus apparently cooked 
> up and didn't tell anyone about and didn't document anywhere. 
> [...]

I certainly didn't cook it up with Linus, and I think it's 
pretty clearly written down in SubmittingPatches:

        Signed-off-by: Random J Developer <random@...eloper.example.org>
        [lucky@...ntainer.example.org: struct foo moved from foo.c to foo.h]
        Signed-off-by: Lucky K Maintainer <lucky@...ntainer.example.org>

It even describes how maintainers append themselves to after the 
existing Signed-off-by chain - and describes how the author of 
the patch adds the first Signed-off-by.

So I think it's pretty clearly defined.

> [...]  I'd never heard about it before and I doubt if many 
> other people knew about it.  And if anyone should have known 
> about it, I should have!
>
> So we have an unknown but probably large number of patches in 
> the tree now which do not follow this rule. [...]

I think all the major Git trees are doing it the way described 
in SubmittingPatches: first signoff is author and maintainers 
append a Signed-off-by to the end.

In practice there's a large number of noise in the tree through, 
as with any information created by humans, to be read by humans 
and not checked by computers. But this does not justify the 
intentional creation of noise I think.

Thanks,

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/