RE: 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: [e-mail]
> [mailto:[e-mail]] On Behalf Of Greg Watson
> Sent: 20 May 2003 04:51
> To: [e-mail]
> 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
> > [e-mail]
> > http://www.clustermatic.org/mailman/listinfo/linuxbios
>
> Linuxbios mailing list
> [e-mail]
> http://www.clustermatic.org/mailman/listinfo/l%3E inuxbios