All,
A few days ago (actually, a couple of weeks at this point),
I wrote to Ron, Jeff, Eric and Ollie, mentioning that I was
thinking about tinkering with some new ideas with respect
to the config system and the filesystem hierarchy. I wanted
to get their reaction before going to the whole list,
because I figured that if they didn't like it it wasn't
worth stressing everyone else with the issue. Anyway,
with their help, I learned a bit more about LinuxBIOS
history and where some sensitivities lie. I'm thankful
for their patience in explaining some of this to me. :-)
Ron's "code reuse" post a few days ago actually was largely
in response to some of the comments I made in explaining
why I wanted to do something with the config system; I had
taken empty directories to indicate that there were some
shortcomings here, but now I understand that the empty
directories are an artifact of CVS braindamage and that
code reuse is just fine.
All this being said, I think that Ron and I agreed that
the config program could still be better, and at least I
would like to work on it some (I'm not about to presume
that anyone else would like me to work on it some... :-)
At this point, I'd like to open a discussion on what people
would like to see in the config system and what they would
*not* like to see, and also to mention some ideas that
are rattling around in my head.
To wit:
It would be nice to have the configuration script work
through a GUI, at least as an option. Quoting Ron on this:
> I would like a Python graphical-style interface that presented you
> with a set of motherboard choices (easy to enumerate from
> src/mainboard/*/*) and a set of checkboxes for options (serial console for
> example).
As far as it goes, this sounds fine. However, I'm
thinking that the functionality of a GUI build tool
would be improved if there were a standard way to find
out more about the various targets. For example, there
are currently option commands which are target-specific.
Rather than hard-code this in the build tool, it seems
to me a better option to have a "config tool config" file
in each source directory along the lines of the existing
"Config" file. Thus, where the existing Config file lists
options and other commands that have been pre-selected
as appropriate for that target, it would be useful from
a GUI tool perspective to have some sort of configuration
file which would somehow list all valid options for that
source directory, rather than just the default options.
I could see doing this either by creating an additional
file listing all the options, or by changing the existing
Config file so that it listed all valid commands but
with markup indicating defaults and mandatory commands,
options and values.
Moving beyond this, it occurs to me as well that, as
more code modules get brought into the LinuxBIOS
tree, e.g. along the lines of what is being discussed
for TIARA and/or etherboot, there is likely to be code
that will require specialized configuration processing
that doesn't necessarily work well with the existing
structure. My sense is that this is something that
is unlikely to be fixable in the context of a single,
monolithic config tool except through extensive hackery
that could easily contribute to bit rot.
It seems to me that a potentially more scalable and
maintainable solution would be to design a structure
within which the owner of a source directory could
extend the config tool via a plug-in. Thus, when
specialized configuration processing is required,
the "config tool config" file could point to a
python script that will handle this task; the interface
to such plug-ins would need to be well-documented to
minimize compatibility problems. In the event that
the configuration task seems more trouble to program
than it would be worth, or for new development where
the configuration activity isn't yet well-defined,
there could simply be a default action, for example
to call a Makefile up into an editor window.
Oe Sun, May 20, 2001 at 10:32:11PM -0600, Ronald G Minnich wrote:
>
> Things I don't like about config. Error handling sucks. Error messages
> suck.
I'd hope to do better in this regard. Clearly, I'm not
adverse to typing... :-) One difficulty in this regard
is how to go about describing to the program what is an
error and what is not an error. Toward this end, one
thing I'd like to consider is the use of XML for the
various configuration files used. There are a number of
reasons why I think that this would be valuable:
* XML parsers are widely available and highly usable.
* There are many Python-based resources for handling
XML.
* The presentation of options can easily be driven
by XML tool configuration files in the filesystem;
the configuration tool itself can be made relatively
small, modular and stable, with almost all tweaking
being done either through the tool configuration
files or through special-purpose plug-ins. Note
that such plug-ins can be provided for source
directories which do not yet support an XML configuration
file.
* It should be possible to leverage the formality
of XML to help improve error handling.
* The content-sensitivity of XML tags helps to make
configuration files somewhat self-documenting.
* The use of XML configuration files is consistent
with what is being done in other open-source projects
such as Gnome.
> I want a 'tags' target so tags files for your mainboard source
> get built automatically and a 'doxygen' target too, so you can build a
> little manual consisting of doxygen info from all the files used to build
> linuxbios for your mainboard. This stuff is all pretty easy.
These should be straightforward, as you say. It does perhaps
suggest that maybe the makefile generation could be modularized
so that new targets could be coded as python modules, and the
configuration GUI could offer a checklist of targets to be
included in the output Makefile, possibly with an optional checkbox
indicating whether a target should be included in "all".
> Config system. You can config a target system with a 10-line command file.
> Config files for components such as mainboard are in the tree with the
> source, and are found automatically. The language is very simple.
This is always a tradeoff; the simplicity of the language can also
limit what can be done with it. However, I think that by distributing
little-changed configuration options out to the relevant source
directories (much as is done now), you can still have a relatively
compact top-level config file, and having a GUIified tool to generate
the config file can minimize the pain from having a comparatively
bulky language involved.
A note about tools: Beyond Python, which is a given that I'm totally
comfortable with, I'd propose using the GTK port of wxWindows
(http://www.wxwindows.org) via the python interface wxPython
(http://www.wxpython.org) as the GUI toolkit. These provide a
very nice widget set that is easily scriptable from Python in
a modular manner. The amount of coding overhead required to
support a wxPython interface is absolutely minimal.
> thanks for your note, it's useful to get this kind of feedback.
>
> ron
I hope that this message gives you a little better idea of
what I have in mind. Optimally, this will spur some constructive
discussion of what people would like the config system to do
for them. As we have something now that is largely working just
fine, I think that there is no big hurry to get this project
done, and it would be good to take some time to gather ideas and
requirements and possibly float a couple of prototypes.
Obviously, if the LinuxBIOS community as a whole does not see this
as a worthwhile effort, it would not make sense to put much
time into it, so please speak up if you think that this is a
Really Bad Idea.
Best regards,
--Bob
