linux-kernel - Re: [PATCH] Factor out common MODULE_INFO content from module*.h files.

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]

Message-ID: <Pine.LNX.4.64.0705201555470.18338@localhost.localdomain>
Date:	Sun, 20 May 2007 16:06:40 -0400 (EDT)
From:	"Robert P. J. Day" <rpjday@...dspring.com>
To:	Sam Ravnborg <sam@...nborg.org>
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, 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.

in that situation, the proper (initial) patch would be one that

1) didn't break what was already there, and
2) allowed people to start cleaning up their files little by little

and when all of the cleanup was allegedly complete, the header files
could be adjusted to their final form.

is any of this making sense?  yes, sam's suggestion is clearly the
simpler one, but it can't be applied without cleaning everything up
*first*.  and without it, people can't start cleaning up code on their
own.

this *has* to be a two-step process.  you may not like the
moduleinfo.h file but think of it as a bridge to get to the final
result, when it can finally be thrown away.

rday
-- 
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================
-
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/