Bug#66578: Module descriptions in modconf
As the de facto package maintainer I will be the first to admit that the
status of the module messages is totally ridiculous. As you pointed out
there are many inaccuracies and omissions.
Some time late last year we looked into revamping the modconf system
completely, however, because of the (at that time) pending potato freeze we
held off on that. Unfortunately six months later we are still in a freeze,
so I am still not able to start a rewrite of the system.
Unfortunately Linux still does not have a universal way of querying modules
for parameters and parameter semantics. There are some facilities for doing
that now, but it is still quite incomplete :-(
To address some of your specific points below:
> 2) The kernel sources
> I'm not very clever with Perl, so I can't overcome the lack of
> comments in the script which digs the source tree. It's hard to
> handle the kernel source tree, but missing CONFIG_SERIAL means
> that many things will go wrong.
The perl script simply goes into your kernel source's and runs through a
two-pass heuristic. On the first pass it builds a hash table that associates
the CONFIG_* parameters in Documentation/Configure.help with the help
message that follows the CONFIG parameter. On the second pass it looks
through the kernel source Makefiles and applies some simple rules to
determine what module name (e.g. lp.o) corresponds with what CONFIG_*
parameter, and in so doing find the appropriate help message.
Because of the lack of standardization in the kernel, this method is bound
to fall. Different parts of the kernel uses different Makefile formats, and
these have a tendency to change over time.
If you have specific questions about the perl script please email me privately
and I will be happy to go over it with you.
> But if I want to help what I have to do? Mantain the Howto? Fix
> the perl script? Write redundant templates? All of this are - at
> least for me - too hard to be done in a few days.
The simple fix right now is to fix the static templates. The templates are
meant to let you override the incorrect info that the automatic parts of the
script might get from the HOWTO or from the kernel source.
> Or, may be, releasing an operating system where it's hard to
> figure out how to use the serial or parallel port is critical
> only to my eyes...
The underlying problem, again, is that I do not know of any way to do what
we are doing (associating module filenames with their descriptions) in a
somewhat automated fashion that is tied to changes in the kernel tree. If we
rely on a totally manual process we are bound to get out of sync with the
kernel. If you have any suggestions on how we can do this, I will be very
happy to entertain them.
Debian Developer <email@example.com>