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:	Sun, 20 May 2007 22:51:16 +0200
From:	Sam Ravnborg <sam@...nborg.org>
To:	"Robert P. J. Day" <rpjday@...dspring.com>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...l.org>
Subject: Re: [PATCH] Factor out common MODULE_INFO content from module*.h files.

On Sun, May 20, 2007 at 04:06:40PM -0400, Robert P. J. Day wrote:
> 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.
> 
> crap, now i remember why i did it the way i did it.
> 
> yes, the way you describe it is a simpler solution, but it would break
> all of the files in the tree that use module parameters and have
> included *only* module.h, and have been getting away with it all this
> time only because module.h currently includes moduleparam.h.
> 
> based on a simple script i have, there are currently 583 files under
> the drivers/ directory *alone* that are like that.  that is, 583 files
> that would need to include moduleparam.h instead of module.h simply to
> continue to compile if the obvious header file fix were made.
The pain is too high for this.
Is seems worthwhile to make the change to module.h but
adding an additional include to > 500 drivers is not worth it.

	Sam
-
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ