From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757537AbXETTw5 (ORCPT ); Sun, 20 May 2007 15:52:57 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1755799AbXETTwu (ORCPT ); Sun, 20 May 2007 15:52:50 -0400 Received: from [216.16.235.2] ([216.16.235.2]:53176 "EHLO rubicon.netdirect.ca" rhost-flags-FAIL-FAIL-OK-OK) by vger.kernel.org with ESMTP id S1755773AbXETTwt (ORCPT ); Sun, 20 May 2007 15:52:49 -0400 X-Originating-Ip: 72.143.65.211 Date: Sun, 20 May 2007 15:51:18 -0400 (EDT) From: "Robert P. J. Day" X-X-Sender: rpjday@localhost.localdomain To: Sam Ravnborg cc: Linux Kernel Mailing List , Andrew Morton Subject: Re: [PATCH] Factor out common MODULE_INFO content from module*.h files. In-Reply-To: <20070520191552.GA25200@uranus.ravnborg.org> Message-ID: References: <20070520191552.GA25200@uranus.ravnborg.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Net-Direct-Inc-MailScanner-Information: Please contact the ISP for more information X-Net-Direct-Inc-MailScanner: Found to be clean X-Net-Direct-Inc-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-16.723, required 5, autolearn=not spam, ALL_TRUSTED -1.80, BAYES_00 -15.00, INIT_RECVD_OUR_AUTH -20.00, RCVD_IN_SORBS_DUL 20.00, TW_VN 0.08) X-Net-Direct-Inc-MailScanner-From: rpjday@mindspring.com Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Sun, 20 May 2007, Sam Ravnborg wrote: > On Sun, May 20, 2007 at 03:06:15PM -0400, Robert P. J. Day wrote: > > > > In order to eventually break the interdependency between the module.h > > and moduleparam.h header files, factor out the common MODULE_INFO > > content into a new header file. > > The moduleinfo.h file looks redundant at first look. > Why not push relevant parts from moduleparam.h (the > MODULE_INFO bits) to module.h and let go of > the include of moduleparam.h in module.h (when you > have fixed the users)? > > In this way we do not add an extra .h file. > And files that needs moduleparam.h will anyway always need module.h. > But not the other way around. no problem, i can go that way, too, but there's just one (admittedly picky) issue associated with that. based on the above, we would have: 1) module.h handling all generic module content, and 2) moduleparam.h would "#include" module.h and add the parameter stuff. fair enough, but note that, with that, if you wanted parameter support, you would need to include *only* "moduleparam.h". are you good with that? (as i said, it's picky, but you'd probably still have a lot of people who, through force of habit, would still #include both just because they think it's necessary. wouldn't hurt, of course, since module.h would be protected against multiple inclusion.) so if you're good with all of the above, i can do that. rday -- ======================================================================== Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://fsdev.net/wiki/index.php?title=Main_Page ========================================================================