[PATCH 08/19] commands: move CMD_MIPS_CPUINFO to commands/Kconfig

[Holger Schurig]

> Can we move example 'cpuinfo' output to *.dox?

That can be done, but it is not done by me. The doxygen is in such a
bad state, that I'm not really wanting to work on it. How many
commands are in doxygen? How sorted are they, how complete are they?
Not even concepts like memory area etc are currently described nicely
there.

Also, when I was doing "make xconfig" and wanted to select the
options, I was looking into the xconfig program, not in some
(suboptimal) doxygen docs. So I think the documentation for this step
should be in the Kconfig in the first place, everything else is then
optional.



If it would be to me, I'd in long-term kill the doxygen. Or have the
doxygen only describe the internal API for barebox programmers.
Currently it mixes internal API and end-user documention, not so nice.

Finally, ideally there would be only one place with command
descriptions (currently we have three: BAREBOX_CMD_FOO macros, Kconfig
entries, doxygen comments). It would be nice if the BAREBOX_FOO ones
become the main one, and that other ones be automatically generated
from them. There could even be a BAREBOX_CMD_HELP_DOXY() macro for
text that just ends up in the doxyfile, but not in the barebox binary.

In fact I already have done a first step towards this. My
not-yet-published scripts/checkhelp.py program. It parses all the *.c
file recursively for the BAREBOX_CMD_foo macros, and checks for
various things (e.g. line length not > 77 characters). As this script
already parses the stuff, it could also be used store information and
output into some different format.

However, priority-wise I still think that all Kconfig entries (for
non-commands) without a help text should get one first, this is more
helpful than some long documentation file. And that barebox develops a
policy where patch with a new Kconfig but without a good documention
would simply be rejected.