config language

[Mark Wilkinson]

Hi Greg, Ron
	Just to chip in my $0.02.

Greg, what you've suggested looks to lend itself towards an XML type
markup.

How about something like this for your example :-

<mainboard vendor="motorola" board="sandpoint">
  <cpu>p5</cpu>
  <pmc vendor="altimus" model="mpc7500">
     <northbridge vendor="motorola" model="mpc107"/>
  </pmc>
  <southbridge vendor="winbond" model="w83c553">
     <superio vendor="NSC" model="pc97307">
        <com number="1"/>
        <com number="2"/>
        <lpt/>
        <keyboard/>
        <hwmonitor/>
     </superio>
  </southbridge>
  <nvram/>
  <flash/>
</mainboard>

It's just a suggestion, but with a properly defined schema, the config
file could be verified/edited easily.

Regards
Mark Wilkinson.

> -----Original Message-----
> From: linuxbios-admin at clustermatic.org
> [mailto:linuxbios-admin at clustermatic.org] On Behalf Of Greg Watson
> Sent: 20 May 2003 04:51
> To: linuxbios at clustermatic.org
> Subject: Re: config language
>
>
> Phew! What a can of worms you've just opened up!
>
> Some comments:
>
> Your proposed syntax seems a bit inconsistent, in that you use
> 'name=<tag>' in some places, but not in others. If you go this way
> then I would suggest using this syntax for all arguments. Also, if
> 'parent' is optional then what does it mean to leave it out? Attached
> to the root?
>
> Defining the tree from bottom-up is somewhat non-intuitive and
> potentially confusing. It seems more natural to define the tree
> structure top-down as follows:
>
> mainboard vendor/model
>    cpu p5
>    southbridge vendor/model
>    end
>    southbridge vendor/model2
>      superio vendor/model
>        ...config...
>      end
>    end
> end
>
> This provides a much more readable description of the hierarchy, and
> also avoids the need to define arbitrary tags just to define the tree.
>
> Parsing is simple: a keyword ('mainboard', etc.) starts a tree node.
> The 'end' keyword ends the current node. Some keywords may be
> terminal so they don't need 'end', eg 'cpu'. Configuration options no
> longer need to be supplied as arguments to a keyword, they can be
> terminal keywords in a node.
>
> This works nicely for the PPC as follows:
>
> mainboard motorola/sandpoint
>    pmc altimus/mpc7500
>      northbridge motorola/mpc107
>    end
>    southbridge windbond/w83c553
>      superio NSC/pc97307
>        com1={1}
>        com2={1}
>        floppy=0
>        lpt=1
>        keyboard=1
>        hwmonitor=1
>      end
>    end
>    nvram
>    flash
> end
>
> I think this also provides a nice way of conceptualizing the
> architecture.
>
> Regards,
>
> Greg
>
> At 8:06 PM -0600 19/5/03, ron minnich wrote:
> >Eric has pointed out to me that we need a tree to properly
> describe the
> >new complex systems such as K8. The current config language is not
> >sufficient to do the job.
> >
> >I've been thinking about mods to the language that preserve
> the current
> >simplicity for the vast majority of motherboards out there, while at
> >the same time allowing a complex hierarchy to be described.
> I think I
> >have an idea.
> >
> >
> >Currently we say things like this:
> >
> >southbridge vendor/model  ...
> >
> >superio vendor/model ...
> >
> >This syntax is actually sufficient for something like 95% of the
> >motherboards we need to support. But what if we have
> >
> >southbridge vendor/model ...
> >southbridge vendor/model ...
> >
> >superio vendor/model ...
> >
> >which southbridge is the superio on?
> >
> >Here is my proposed change
> >
> >southbridge vendor/model[=<tag>] [parent=<tag>] ...
> >
> >superio vendor/model[=<tag>] [parent=<tag>] ...
> >
> >(note this syntax applies to all the types of parts)
> >
> >Consider the simple case. The one southbridge is given a
> default tag of
> >southbridge, with the default parent of northbridge. The superio is
> >given the default tag of superio, with the default parent of
> >southbridge. It all works.
> >
> >Consider the hard case.
> >
> >southbridge intel/xyz=sb1 ...
> >southbridge intel/xyz=sb2 ...
> >
> >superio NSC/abs parent=sb1 ...
> >
> >If there is more than one northbridge, then we can set the
> parent tag
> >for the southbridge.
> >
> >This syntax allows arbitrary trees to be described; it is as
> simple in
> >the base case as the current one; and it should be fairly
> >straightforward to implement. Computing the path to a given part is
> >then easy.
> >
> >Some flexibility in the tags should be possible. The tag
> could allude
> >to an actual tag, or a part type (southbridge), or a part
> >vendor/manufacturer pair (intel/xyz). As long as the tag specifies
> >something unique, it should be acceptable.
> >
> >Another way to do it is this:
> >
> >southbridge [tag=<tag>] [parent=<tag>]
> >
> >any preference for syntax?
> >
> >Comments?
> >
> >ron
> >
> >_______________________________________________
> >Linuxbios mailing list
> >Linuxbios at clustermatic.org
> >http://www.clustermatic.org/mailman/listinfo/linuxbios
>
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/l> inuxbios
>