On Thu, 26 Apr 2007 15:54:26 +0200 Adrian Bunk wrote: > On Thu, Apr 26, 2007 at 12:41:41PM +0200, Rene Herman wrote: > > On 04/26/2007 03:18 AM, Andrew Morton wrote: > > > >> On Mon, 23 Apr 2007 14:32:36 +0200 Rene Herman <[EMAIL PROTECTED]> > >> wrote: > >>> Provide MODULE_MAINTAINER() as a convenient place to stick a name and > >>> email address both for drivers having multiple (current and > >>> non-current) authors and for when someone who wants to maintain a > >>> driver isn't so much an author. > > > > [ snip ] > > > >> I'm not sure we want to do this - that's what ./MAINTAINERS is for and we > >> end up having to maintain the same info in two places. > > > > [EMAIL PROTECTED]:~$ less ./MAINTAINERS > > ./MAINTAINERS: No such file or directory > > > > MAINTAINERS is a developers thing, not users, yet a maintainer is someone > > who other than by developers wants to be contacted by users of a particular > > driver. Right now, a module exports a set of name and email addresses > > through the MODULE_AUTHOR tag but given multiple current and non-current > > authors, completely or largely orphaned drivers (I have a lot of junk PC > > hardware so I come across those relatively often) and people who might be > > interested in taking care of a driver but who do not consider themselves an > > author for (upto now) having done a s/, struct pt_regs// on it, that tag > > only confuses the issue of whom to contact. > > > > And it in fact even does so when Joe does know about a MAINTAINERS file and > > does happen to have a kernel source tree lying around somewhere. With one > > set of addresses displayed prominently inside the sourcecode of the very > > driver and another one of in a MAINTAINERS file, the first one wins. Joe > > would have to be very new to Linux to trust something in the tree that's > > not actually compiled over something that is. > > > > As the first response in this thread Cristoph Hellwig stated that > > MODULE_AUTHOR serves no purpose other than what MODULE_MAINTAINER would be > > serving. Others agreed and Adrian Bunk suggested deleting MODULE_AUTHOR > > outright. > > > > That would actually also serve my purposes; if there's no MODULE_AUTHOR > > confusing the issue, I don't so much need a MODULE_MAINTAINER to fix it > > again. I believe having "modinfo" (optionally!) display a contact address > > for a driver might be a user advantage, but with all the wrong addresses > > gone, I don't really care deeply; MODULE_AUTHOR doesn't serve the purpose > > today and with it gone the user at least knows he needs to look elsewhere. > > MODULE_AUTHOR is also a credits issue but the information can be > > transferred to copyright headers. It would obviously also fix any possible > > maintenance issues. > > > > Alan Cox believes that having author information embedded in the module > > serves a legal purpose though and objects to removal.
Wouldn't a /* comment */ satisfy AUTHOR needs? It gives deserved attribution and should serve legal purpose just as well as a macro does (IANAL!). IMO we want MAINTAINER info in the macro and in modinfo, so I'm for removing MODULE_AUTHOR and just having MAINTAINER. > >... > > Let me try to summarize the points: > - you think MODULE_AUTHOR without MODULE_MAINTAINER confuses users > - Alan wants MODULE_AUTHOR to stay for easing showing authorship of code > to people > - I (and others) think MODULE_MAINTAINER wouldn't make sense > > Is there any good solution for this? > E.g. modinfo could be changed to no longer defaulting to show the author? --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
