Date: Sun, 28 Mar 2004 12:40:48 +0300 From: Alexey Zelkin <phantom@FreeBSD.org> To: arch@FreeBSD.org Subject: CFD: XMLification of NOTES Message-ID: <20040328094048.GA40406@phantom.cris.net>
next in thread | raw e-mail | index | archive | help
hi,
This weekend I have got some spare time (due to illness) and in order to get
some rest from current tasks decided to pass thru old TODO file. Most
interesting task got my attention was old item related to XMLification NOTES.
Important advantage of this step (IMO) is to provide possibility to
check dependency/conflicts of kernel configuration file to end users.
Another possible advantage is great simplification of task writing GUI
kernel configurator. If somebody volunteer, I'd be happy to write code
related to XML handling (in case if current code not enough).
Since -CURRENT now has libexpat imported (thanks Poul-Henning) I decided to
give it a try.
Now I have machine-independent and i386-machdep NOTES converted to XML
format (described below) and wrote basic code which loads, validate XML
(I have found that libexpat's support for DTD is very basic and it does
not provide possibility to check if XML file completely conforms to DTD)
and generate LINT which is almost same to LINT generated using current way).
The only difference is order of entries, but 'sort -u' on both LINTs gives
same result.
At this point I would like to start some kind of discussion and listen for
your ideas which features you'd like to see in application which will be
handling these XMLs.
I propose to have following ones:
. basic validation of specific or all XML files (all NOTES files).
. LINT generation for specific architecture
. checking of provided kernel configuration file against NOTES
a) check for missing dependencies
b) check for conflicting options
c) warn about obsolete options (missing in NOTES.xml)
. check for missing dependencies. Not sure yet about method, but I think
following way would work for us:
a) generate set of kernel configuration files each containing 'required'
kernel options (machine, ident, maxusers, etc)
b) put one option/device and its dependencies into this file
c) config/compile it. if compile fails, then assume that some dependency
is missing. find missing dependency and register it into XML file.
. check for missing conflicts. Not sure about this. Ideas are welcome!
. PUT YOUR ENTRY HERE!
According XML structure. It should look like:
<notes>
<section id="ID">
<title>Section Title</title>
<desc>Multiline section description</desc>
<entry type="(options|device|etc)" id="ID2">
<conflicts options="ID3"/>
<depends device="ID4"/>
<lint value="1"/>
<lint exclude="yes"/>
<title>Entry title</title>
<desc>Entry description</desc>
</entry>
</section>
</notes>
For example (two random entries):
<notes>
<section id="SMP">
<title>Symmetric MultiProcessor (SMP) Support</title>
<desc>SMP enables building of a Symmetric MultiProcessor Kernel</desc>
<entry type="options" id="SMP">
<conflicts cpu="i386"/>
<title>SMP kernel</title>
<desc>This option enables building of SMP kernel</desc>
</entry>
<entry type="options" id="MUTEX_NOINLINE">
<depends options="SMP"/>
<title>Do not inline mutex operations</title>
<desc>
MUTEX_NOINLINE forces mutex operations to call functions to perform each
operation rather than inlining the simple cases. This can be used to
shrink the size of the kernel text segment. Note that this behavior is
already implied by the INVARIANT_SUPPORT, INVARIANTS, MUTEX_PROFILING,
and WITNESS options.
</desc>
</entry>
</section>
<notes>
--
/* Alexey Zelkin && Independent Contractor */
/* phantom(at)FreeBSD.org && http://www.FreeBSD.org/java */
/* phantom(at)cris.net && http://www.FreeBSD.org.ua/ */
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040328094048.GA40406>