CFD: XMLification of NOTES

From: Alexey Zelkin (phantom_at_FreeBSD.org)
Date: 03/28/04

  • Next message: jitendra pande: "Problem with usb in FreeBSD 4.8....help!!!" 
    Date: Sun, 28 Mar 2004 12:40:48 +0300
To: arch@FreeBSD.org

    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/  */
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
  • Next message: jitendra pande: "Problem with usb in FreeBSD 4.8....help!!!"
    • Quantcast