>> How about actually checking if the unresolved symbols are available
>> in the GPLONLY area? That would allow you to be more precise.
> I would have to check for all the permutations between module and
> kernel. With and without symbol versions, with and without gplonly,
> with and without ppc64 function descriptor renaming, with and
> without ia64 function descriptor renaming, ...
>
> Given the current modutils code, that is just too messy. The code
> was written for a single set of names and it has been hacked since
> then, with special cases added onto special cases. The symbol
> handling needs a complete rewrite, which will occur in modutils 2.5.
> In modutils 2.4 I just ignore the gplonly symbols during symbol
> import unless the module is gpl licenced. Simpler, if less precise.
> Since it only affects BOMs, I don't really care that much about
> precise error messages.
Rather than ignore them, set a flag if you see any of them, then make
the message depend on whether the said flag is set or not.
Best wishes from Riley.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/