diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
index dfde0e8..81cbf95 100644
--- a/scripts/mod/modpost.c
+++ b/scripts/mod/modpost.c
@@ -1187,16 +1187,19 @@ static void add_header(struct buffer *b,
/**
* Record CRCs for unresolved symbols
**/
-static void add_versions(struct buffer *b, struct module *mod)
+static int add_versions(struct buffer *b, struct module *mod)
{
struct symbol *s, *exp;
+ int err = 0;
for (s = mod->unres; s; s = s->next) {
exp = find_symbol(s->name);
if (!exp || exp->module == mod) {
- if (have_vmlinux && !s->weak)
+ if (have_vmlinux && !s->weak) {
warn("\"%s\" [%s.ko] undefined!\n",
s->name, mod->name);
+ err = 1;
+ }
continue;
}
s->module = exp->module;
@@ -1205,7 +1208,7 @@ static void add_versions(struct buffer *
}
if (!modversions)
- return;
+ return err;
buf_printf(b, "\n");
buf_printf(b, "static const struct modversion_info ____versions[]\n");
@@ -1225,6 +1228,8 @@ static void add_versions(struct buffer *
}
buf_printf(b, "};\n");
+
+ return err;
}
static void add_depends(struct buffer *b, struct module *mod,
@@ -1402,6 +1407,7 @@ int main(int argc, char **argv)
char *kernel_read = NULL, *module_read = NULL;
char *dump_write = NULL;
int opt;
+ int err;
while ((opt = getopt(argc, argv, "i:I:mo:a")) != -1) {
switch(opt) {
@@ -1441,6 +1447,8 @@ int main(int argc, char **argv)
check_exports(mod);
}
+ err = 0;
+
for (mod = modules; mod; mod = mod->next) {
if (mod->skip)
continue;
@@ -1448,7 +1456,7 @@ int main(int argc, char **argv)
buf.pos = 0;
add_header(&buf, mod);
- add_versions(&buf, mod);
+ err |= add_versions(&buf, mod);
add_depends(&buf, mod, modules);
add_moddevtable(&buf, mod);
add_srcversion(&buf, mod);
@@ -1460,5 +1468,5 @@ int main(int argc, char **argv)
if (dump_write)
write_dump(dump_write);
- return 0;
+ return err;
}
Kirill Korotaev writes:
> At stage 2 modpost utility is used to check modules.
> In case of unresolved symbols modpost only prints warning.
>
> IMHO it is a good idea to fail compilation process in case of
> unresolved symbols, since usually such errors are left unnoticed,
> but kernel modules are broken.
Total disagree. A big warning is appropriate, but failure
is unnecessary and harmful.
Consider a big modular config, which has loads of modules
I'll never need or use. Even if $random_module has an
unresolved symbol, the kernel+modules will still work with
a fairly high degree of probability, allowing me to test
other things even though $random_module is (temporarily)
broken.
Your suggestion would either force me to reconfigure to
avoid the broken module (allowing me to forget about it),
or it would prevent me from testing that kernel at all
until I or someone else fixed the $random_module breakage.
Either way, testing suffers.
On Tue, Sep 05, 2006 at 05:47:25PM +0400, Kirill Korotaev wrote:
> At stage 2 modpost utility is used to check modules.
> In case of unresolved symbols modpost only prints warning.
>
> IMHO it is a good idea to fail compilation process in case of
> unresolved symbols, since usually such errors are left unnoticed,
> but kernel modules are broken.
The primary reason why we do not fail in this case is that building
external modules often result in unresolved symbols at modpost time.
And there is many legitime uses of external modules that we shall support.
Sam
On Tue, Sep 05, 2006 at 05:31:59PM +0200, Sam Ravnborg wrote:
> On Tue, Sep 05, 2006 at 05:47:25PM +0400, Kirill Korotaev wrote:
> > At stage 2 modpost utility is used to check modules.
> > In case of unresolved symbols modpost only prints warning.
> >
> > IMHO it is a good idea to fail compilation process in case of
> > unresolved symbols, since usually such errors are left unnoticed,
> > but kernel modules are broken.
>
> The primary reason why we do not fail in this case is that building
> external modules often result in unresolved symbols at modpost time.
>
> And there is many legitime uses of external modules that we shall support.
Is there a way we can get this only for building the kernel itself?
In this case an unresolved symbol is a real bug that should cause an
abort of the compilation.
I'm often doing compile tests for the kernel, and the current warnings
are too easy to miss.
> Sam
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
Sam Ravnborg wrote:
> On Tue, Sep 05, 2006 at 05:47:25PM +0400, Kirill Korotaev wrote:
>
>>At stage 2 modpost utility is used to check modules.
>>In case of unresolved symbols modpost only prints warning.
>>
>>IMHO it is a good idea to fail compilation process in case of
>>unresolved symbols, since usually such errors are left unnoticed,
>>but kernel modules are broken.
>
>
> The primary reason why we do not fail in this case is that building
> external modules often result in unresolved symbols at modpost time.
>
> And there is many legitime uses of external modules that we shall support.
ok. is it ok for you to introduce new Make target 'modules_check'?
Thanks,
Kirill
Adrian Bunk wrote:
> On Tue, Sep 05, 2006 at 05:31:59PM +0200, Sam Ravnborg wrote:
>
>>On Tue, Sep 05, 2006 at 05:47:25PM +0400, Kirill Korotaev wrote:
>>
>>>At stage 2 modpost utility is used to check modules.
>>>In case of unresolved symbols modpost only prints warning.
>>>
>>>IMHO it is a good idea to fail compilation process in case of
>>>unresolved symbols, since usually such errors are left unnoticed,
>>>but kernel modules are broken.
>>
>>The primary reason why we do not fail in this case is that building
>>external modules often result in unresolved symbols at modpost time.
>>
>>And there is many legitime uses of external modules that we shall support.
> Is there a way we can get this only for building the kernel itself?
> In this case an unresolved symbol is a real bug that should cause an
> abort of the compilation.
IMHO for kernel linking will fail...
Don't you consider the kernel to be broken if suddenly one of your modules
began to have unresolved symbols?
> I'm often doing compile tests for the kernel, and the current warnings
> are too easy to miss.
exactly. and I'm pretty sure, that vendors have the same problem.
Thanks,
Kirill
On Wed, Sep 06, 2006 at 07:05:51PM +0400, Kirill Korotaev wrote:
> Adrian Bunk wrote:
> >On Tue, Sep 05, 2006 at 05:31:59PM +0200, Sam Ravnborg wrote:
> >
> >>On Tue, Sep 05, 2006 at 05:47:25PM +0400, Kirill Korotaev wrote:
> >>
> >>>At stage 2 modpost utility is used to check modules.
> >>>In case of unresolved symbols modpost only prints warning.
> >>>
> >>>IMHO it is a good idea to fail compilation process in case of
> >>>unresolved symbols, since usually such errors are left unnoticed,
> >>>but kernel modules are broken.
> >>
> >>The primary reason why we do not fail in this case is that building
> >>external modules often result in unresolved symbols at modpost time.
> >>
> >>And there is many legitime uses of external modules that we shall support.
>
> >Is there a way we can get this only for building the kernel itself?
s/kernel itself/modules shipped with the kernel/
> >In this case an unresolved symbol is a real bug that should cause an
> >abort of the compilation.
> IMHO for kernel linking will fail...
>
> Don't you consider the kernel to be broken if suddenly one of your modules
> began to have unresolved symbols?
>...
> Thanks,
> Kirill
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Wed, Sep 06, 2006 at 07:05:10PM +0400, Kirill Korotaev wrote:
> Sam Ravnborg wrote:
> >On Tue, Sep 05, 2006 at 05:47:25PM +0400, Kirill Korotaev wrote:
> >
> >>At stage 2 modpost utility is used to check modules.
> >>In case of unresolved symbols modpost only prints warning.
> >>
> >>IMHO it is a good idea to fail compilation process in case of
> >>unresolved symbols, since usually such errors are left unnoticed,
> >>but kernel modules are broken.
> >
> >
> >The primary reason why we do not fail in this case is that building
> >external modules often result in unresolved symbols at modpost time.
> >
> >And there is many legitime uses of external modules that we shall support.
> ok. is it ok for you to introduce new Make target 'modules_check'?
In top-level Makefile we already distingush between external modules and
internal modules. See the different calls to Makefile.modpost
Could you try updating your patch so in the normal case we exit with
a fail in case of unresolved symbols but if a specific flag is specified
we only warn on unresolved symbols.
And then introduce the nw flag only for external modules in the
top-level Makefile.
Sam