config language

[Greg Watson]

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