linux-kernel - Re: linux-next: manual merge of the async

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] [day] [month] [year] [list]

Date:	Sat, 28 May 2011 10:20:53 +0200
From:	Jean Delvare <khali@...ux-fr.org>
To:	Dan Williams <dan.j.williams@...el.com>
Cc:	Stephen Rothwell <sfr@...b.auug.org.au>,
	linux-next@...r.kernel.org, linux-kernel@...r.kernel.org,
	Havard Skinnemoen <hskinnemoen@...il.com>,
	Jiri Kosina <jkosina@...e.cz>,
	Viresh Kumar <viresh.kumar@...com>
Subject: Re: linux-next: manual merge of the async_tx tree with Linus' tree

Hi Dan,

On Fri, 27 May 2011 12:08:37 -0700, Dan Williams wrote:
> On Fri, May 27, 2011 at 12:53 AM, Jean Delvare <khali@...ux-fr.org> wrote:
> > Hi Stephen, Dan,
> >
> > On Fri, 27 May 2011 13:30:03 +1000, Stephen Rothwell wrote:
> >> Today's linux-next merge of the async_tx tree got a conflict in
> >> drivers/dma/dw_dmac.c between commit e05503ef1186 ("Haavard Skinnemoen
> >> has left Atmel") from Linus' tree and commit aecb7b64dd9e
> >> ("dmaengine/dw_dmac: Update maintainer-ship") from the async_tx tree.
> >>
> >> Just context changes.  I fixed it up (see below) and can carry the fix as
> >> necessary.
> >
> > Dan's patch is just plain wrong. MODULE_AUTHOR is about who wrote the
> > code, not who maintains it. A change of maintainer should lead to an
> > update or addition to file MAINTAINERS.
> 
> The patch in question did also update MAINTAINERS.  Since Viresh has
> done a good amount of work on the driver (top-developer by commits
> since the initial merge) and likely cares about user reports (now that
> he has stepped up to maintain it) is there a reason that he should not
> have his own MODULE_AUTHOR line in the driver as well?

Sorry, I guess I shouldn't have commented on a driver I don't know
anything about. Furthermore, I didn't read the patch carefully, it is
adding a MODULE_AUTHOR, when I thought it was replacing it (in all
honestly I didn't even know it was possible to have more than one
MODULE_AUTHOR statement per driver.)

So really it's alright, just ignore me, and sorry for the noise.

> > (...)
> > (As a side note, the relevance of MODULE_AUTHOR given the development
> > and maintenance model the Linux kernel has embraced can certainly be
> > discussed, but that's a different story.)
> 
> We don't seem to have documentation around it, but making a bunch of
> commits and stepping up to be a maintainer seems enough justification
> to have your contact info show up in modinfo...

My point is that the authors of a driver aren't necessarily the right
persons to contact in case of problem. Given that distribution users
won't find the MAINTAINERS file (and the files entries there point to
source files anyway), users don't have a proper way to find the right
contact. I suspect that driver authors are better located in the source
code (it is already there most of the time) and we'd rather need a
MODULE_MAINTAINER() macro, ideally generated automatically from
MAINTAINERS. But again it is a wider debate, not related with the
problem at hand.

-- 
Jean Delvare
--
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/