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>