Tweaking the libxlu bison grammar to include nested lists

Tweaking the libxlu bison grammar to include nested lists

[Sunder]

[-- Attachment #1.1: Type: text/plain, Size: 1052 bytes --]

Hello everyone,

I'm new to the Xen community and this is my first attempt towards a patch.
I've been given to understand that the config parser's grammar needs to be
modified to accept nested lists. I've been trying to tweak the code and
would need a bit of help in understanding the actions that are being
invoked (*store/*set/*mk, especially *mk which seems to be called with
different 2nd args based on where/what's found, which is quite confusing to
me). I also think the grammar could be further reduced as below. I'd love
to hear the expert opinions -- have I covered all cases? Are the right
actions being invoked?

Thanks!
Sunder

* filename: <xen>/tools/libxl/libxlu_cfg_y.y

/*reduced grammar (mainly for understanding and local testing):*/

stmts: | stmts stmt
stmt: ID '=' expr nl { xlu__cfg_set_store(ctx,$1,$3,@3.first_line); }
expr:
atom { $$= xlu__cfg_set_mk(ctx,1,$1); }
| list
| expr ',' atom { xlu__cfg_set_add(ctx,$1,$3); $$= $1; }
| expr ',' list

list: '[' expr ']' { $$= xlu__cfg_set_mk(ctx,0,0); }
atom: NUM|STR
nl: NL | nl NL

[-- Attachment #1.2: Type: text/html, Size: 1847 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: Tweaking the libxlu bison grammar to include nested lists

[Elena Ufimtseva]

On Tue, Jul 22, 2014 at 10:34 AM, Sunder <u89012@gmail.com> wrote:
> Hello everyone,
>
> I'm new to the Xen community and this is my first attempt towards a patch.
> I've been given to understand that the config parser's grammar needs to be
> modified to accept nested lists. I've been trying to tweak the code and
> would need a bit of help in understanding the actions that are being invoked
> (*store/*set/*mk, especially *mk which seems to be called with different 2nd
> args based on where/what's found, which is quite confusing to me). I also
> think the grammar could be further reduced as below. I'd love to hear the
> expert opinions -- have I covered all cases? Are the right actions being
> invoked?
>
> Thanks!
> Sunder
>
> * filename: <xen>/tools/libxl/libxlu_cfg_y.y
>
> /*reduced grammar (mainly for understanding and local testing):*/
>
> stmts: | stmts stmt
> stmt: ID '=' expr nl { xlu__cfg_set_store(ctx,$1,$3,@3.first_line); }
> expr:
> atom { $$= xlu__cfg_set_mk(ctx,1,$1); }
> | list
> | expr ',' atom { xlu__cfg_set_add(ctx,$1,$3); $$= $1; }
> | expr ',' list
>
> list: '[' expr ']' { $$= xlu__cfg_set_mk(ctx,0,0); }
> atom: NUM|STR
> nl: NL | nl NL
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>

CC ing Ian.

Ian, this comes from conversation about configuration of vNUMA
distances we had some time ago.
In that conversation we wanted to see vNUMA distance array look
something like this in the config file:

vdistance = [[10,20,25],[20,10,20],[25, 20. 10]]
or a shorter version, but I would start with fully defined at first.

Will be that what Sunder asks a acceptable solution.

Thank you!


-- 
Elena

Re: Tweaking the libxlu bison grammar to include nested lists

[Ian Campbell]

On Wed, 2014-07-23 at 02:12 -0400, Elena Ufimtseva wrote:
> On Tue, Jul 22, 2014 at 10:34 AM, Sunder <u89012@gmail.com> wrote:
> > Hello everyone,
> >
> > I'm new to the Xen community and this is my first attempt towards a patch.
> > I've been given to understand that the config parser's grammar needs to be
> > modified to accept nested lists. I've been trying to tweak the code and
> > would need a bit of help in understanding the actions that are being invoked
> > (*store/*set/*mk, especially *mk which seems to be called with different 2nd
> > args based on where/what's found, which is quite confusing to me). I also
> > think the grammar could be further reduced as below. I'd love to hear the
> > expert opinions -- have I covered all cases? Are the right actions being
> > invoked?
> >
> > Thanks!
> > Sunder
> >
> > * filename: <xen>/tools/libxl/libxlu_cfg_y.y
> >
> > /*reduced grammar (mainly for understanding and local testing):*/
> >
> > stmts: | stmts stmt
> > stmt: ID '=' expr nl { xlu__cfg_set_store(ctx,$1,$3,@3.first_line); }
> > expr:
> > atom { $$= xlu__cfg_set_mk(ctx,1,$1); }
> > | list
> > | expr ',' atom { xlu__cfg_set_add(ctx,$1,$3); $$= $1; }
> > | expr ',' list
> >
> > list: '[' expr ']' { $$= xlu__cfg_set_mk(ctx,0,0); }
> > atom: NUM|STR
> > nl: NL | nl NL
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
> >
> 
> CC ing Ian.

You want Ian J for questions about the parser. CCd.

> Ian, this comes from conversation about configuration of vNUMA
> distances we had some time ago.
> In that conversation we wanted to see vNUMA distance array look
> something like this in the config file:
> 
> vdistance = [[10,20,25],[20,10,20],[25, 20. 10]]
> or a shorter version, but I would start with fully defined at first.

An alternative which would be less work right now would be:
vdistance = [ "10,20,25", "20,10,20" ,... ]

Not ideal, sure.

> Will be that what Sunder asks a acceptable solution.

I'm not sure what Sunder is asking TBH, it looks like queries about how
things work rather than a proposal for a change to me, but perhaps
that's just because I'm not familiar with the existing grammar.

Ian.

Re: Tweaking the libxlu bison grammar to include nested lists

[Dario Faggioli]

[-- Attachment #1.1: Type: text/plain, Size: 1528 bytes --]

On mer, 2014-07-23 at 10:32 +0100, Ian Campbell wrote:
> On Wed, 2014-07-23 at 02:12 -0400, Elena Ufimtseva wrote:

> You want Ian J for questions about the parser. CCd.
> 
> > Ian, this comes from conversation about configuration of vNUMA
> > distances we had some time ago.
> > In that conversation we wanted to see vNUMA distance array look
> > something like this in the config file:
> > 
> > vdistance = [[10,20,25],[20,10,20],[25, 20. 10]]
> > or a shorter version, but I would start with fully defined at first.
> 
> An alternative which would be less work right now would be:
> vdistance = [ "10,20,25", "20,10,20" ,... ]
> 
+1

> Not ideal, sure.
> 
Not even that bad, at least until lists of lists will be there.

A possible issue is that, at that point, we'll have to support the [""]
syntax indefinitely, for backward compatibility, but that does not sound
that bad either.

> > Will be that what Sunder asks a acceptable solution.
> 
> I'm not sure what Sunder is asking TBH, it looks like queries about how
> things work rather than a proposal for a change to me, but perhaps
> that's just because I'm not familiar with the existing grammar.
> 
I know next to nothing about the pareser, sorry. :-(

Regards,
Dario

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: Tweaking the libxlu bison grammar to include nested lists

[Ian Jackson]

Dario Faggioli writes ("Re: [Xen-devel] Tweaking the libxlu bison grammar to include nested lists"):
> On mer, 2014-07-23 at 10:32 +0100, Ian Campbell wrote:
> > On Wed, 2014-07-23 at 02:12 -0400, Elena Ufimtseva wrote:
> > You want Ian J for questions about the parser. CCd.
> > > vdistance = [[10,20,25],[20,10,20],[25, 20. 10]]
> > > or a shorter version, but I would start with fully defined at first.

I have no objection to that in principle.

The existing representation in XLU_ConfigSetting is rather poor for
this unfortunately.  This would have to be fixed and the resulting
patch would be substantial.  But it's all private inside libxlu so
that doesn't pose any problem in principle - it's just some work.

Ian.