Mailing List Archive: VMOD havoc generating patch

VMOD havoc generating patch

Jan 28, 2019, 4:54 AM

Post #1 of 8 (1197 views)

Ticket 2810 is about the names generated by vmodtool and vcc, and
while there is a good intellectual argument for getting it right,
I am a little bit worried about how much havoc that causes.

This is a WIP patch headed in that direction, and I would like to
hear input from VMOD writers.

Ideally with this stuff finished, VMOD writers can version their
vmods using $Prefix and you will then be able to import multiple
different versions of the same VMOD in the same VCL. Not sure that
is a good thing to do, but it proves that the name-space issue is
solved.

See the changes to the in-tree vmods for how this will look for you.

--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

Re: VMOD havoc generating patch [ In reply to ]

dridi at varni

Feb 4, 2019, 11:26 AM

Post #2 of 8 (1194 views)

Permalink

On Mon, Jan 28, 2019 at 1:55 PM Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:
>
> Ticket 2810 is about the names generated by vmodtool and vcc, and
> while there is a good intellectual argument for getting it right,
> I am a little bit worried about how much havoc that causes.
>
> This is a WIP patch headed in that direction, and I would like to
> hear input from VMOD writers.
>
> Ideally with this stuff finished, VMOD writers can version their
> vmods using $Prefix and you will then be able to import multiple
> different versions of the same VMOD in the same VCL. Not sure that
> is a good thing to do, but it proves that the name-space issue is
> solved.
>
> See the changes to the in-tree vmods for how this will look for you.

I waited until my weekly CI against master would choke on this change,
and it's very easy to support both before and after if your baseline
is 6.0, which is more than fine since 4.1 only has a couple months to
live:

#include "vcc_$VMOD_if.h"

/* Varnish < 6.2 compat */
#ifndef VPFX
#define VPFX(a) vmod_ ## a
#define VARGS(a) vmod_ ## a ## _arg
#define VENUM(a) vmod_enum_ ## a
#endif

I didn't try on a vmod with a $Prefix stanza, but I'm sure it can be
helped if that snippet is not enough.

Dridi
_______________________________________________
varnish-dev mailing list
varnish-dev@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev

Re: VMOD havoc generating patch [ In reply to ]

phk at phk

Feb 4, 2019, 11:30 AM

Post #3 of 8 (1194 views)

Permalink

--------
In message <CABoVN9BOLePiYW3tVLVj1vK6fOn23YkHw2znpCTvf936sL7Tcw@mail.gmail.com>, Dridi Boukelmoune writes:
>On Mon, Jan 28, 2019 at 1:55 PM Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:

>I waited until my weekly CI against master would choke on this change,
>and it's very easy to support both before and after if your baseline
>is 6.0, which is more than fine since 4.1 only has a couple months to
>live:
>
> #include "vcc_$VMOD_if.h"
>
> /* Varnish < 6.2 compat */
> #ifndef VPFX
> #define VPFX(a) vmod_ ## a
> #define VARGS(a) vmod_ ## a ## _arg
> #define VENUM(a) vmod_enum_ ## a
> #endif
>
>I didn't try on a vmod with a $Prefix stanza, but I'm sure it can be
>helped if that snippet is not enough.

Yes, that would go a long way towards compatibility.

--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
_______________________________________________
varnish-dev mailing list
varnish-dev@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev

Re: VMOD havoc generating patch [ In reply to ]

dridi at varni

Feb 4, 2019, 1:25 PM

Post #4 of 8 (1194 views)

Permalink

On Mon, Feb 4, 2019 at 8:30 PM Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:
>
> --------
> In message <CABoVN9BOLePiYW3tVLVj1vK6fOn23YkHw2znpCTvf936sL7Tcw@mail.gmail.com>, Dridi Boukelmoune writes:
> >On Mon, Jan 28, 2019 at 1:55 PM Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:
>
> >I waited until my weekly CI against master would choke on this change,
> >and it's very easy to support both before and after if your baseline
> >is 6.0, which is more than fine since 4.1 only has a couple months to
> >live:
> >
> > #include "vcc_$VMOD_if.h"
> >
> > /* Varnish < 6.2 compat */
> > #ifndef VPFX
> > #define VPFX(a) vmod_ ## a
> > #define VARGS(a) vmod_ ## a ## _arg
> > #define VENUM(a) vmod_enum_ ## a
> > #endif
> >
> >I didn't try on a vmod with a $Prefix stanza, but I'm sure it can be
> >helped if that snippet is not enough.
>
> Yes, that would go a long way towards compatibility.

It seems incomplete though, currently the $Prefix is applied all over
the place and the VPFX macro isn't used for function names. Is that
still work in progress?

Dridi
_______________________________________________
varnish-dev mailing list
varnish-dev@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev

Re: VMOD havoc generating patch [ In reply to ]

phk at phk

Feb 4, 2019, 1:29 PM

Post #5 of 8 (1194 views)

Permalink

--------
In message <CABoVN9AUh=DHA5Xt38=bJMAfOGZ=q1pooxG1wH_2UBkVWnYcrA@mail.gmail.com>, Dridi Boukelmoune writes:
>On Mon, Feb 4, 2019 at 8:30 PM Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:

>It seems incomplete though, currently the $Prefix is applied all over
>the place and the VPFX macro isn't used for function names. Is that
>still work in progress?

You mean the in-tree vmods ?

Yes, I only applied the necessary macros to make things work again,
in order to highlight that you dont *have* to use the macros to
write/port a VMOD to the new world order.

After the dust has settled and march release is out, I think we
should fully macro-ize the in-tree VMODS, but if you guys think
it is a better idea to go the full step now, I'm fine with that.

--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
_______________________________________________
varnish-dev mailing list
varnish-dev@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev

Re: VMOD havoc generating patch [ In reply to ]

dridi at varni

Feb 4, 2019, 11:16 PM

Post #6 of 8 (1194 views)

Permalink

On Mon, Feb 4, 2019 at 10:29 PM Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:
>
> --------
> In message <CABoVN9AUh=DHA5Xt38=bJMAfOGZ=q1pooxG1wH_2UBkVWnYcrA@mail.gmail.com>, Dridi Boukelmoune writes:
> >On Mon, Feb 4, 2019 at 8:30 PM Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:
>
> >It seems incomplete though, currently the $Prefix is applied all over
> >the place and the VPFX macro isn't used for function names. Is that
> >still work in progress?
>
> You mean the in-tree vmods ?

No, I mean when I look at the generated vcc_$VMOD_if.h, I see many
occurrences of the $Prefix that are not guarded by VPFX() macros.

> Yes, I only applied the necessary macros to make things work again,
> in order to highlight that you dont *have* to use the macros to
> write/port a VMOD to the new world order.

Right, but it's very convenient to maintain 6.0 source compatibility :3

> After the dust has settled and march release is out, I think we
> should fully macro-ize the in-tree VMODS, but if you guys think
> it is a better idea to go the full step now, I'm fine with that.

The in-tree C files don't need to be macro-ized, I was mostly
concerned by the if.h file generated by vmodtool. But even that
shouldn't matter too much.

Taking my snippet and applying s/vmod/$Prefix/ to it is probably enough.

Dridi
_______________________________________________
varnish-dev mailing list
varnish-dev@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev

Re: VMOD havoc generating patch [ In reply to ]

phk at phk

Feb 5, 2019, 1:17 AM

Post #7 of 8 (1194 views)

Permalink

--------
In message <CABoVN9DZkhCtchRvBzh+zP0jwheex1=WVFdOMC7NJ-MfFgyiGA@mail.gmail.com>, Dridi Boukelmoune writes:

>No, I mean when I look at the generated vcc_$VMOD_if.h, I see many
>occurrences of the $Prefix that are not guarded by VPFX() macros.

The VPFX/VARGS/VENUM macros are mostly intended as convenience for the
files the vmod-author writes.

I didn't VPFX the prototypes to not _force_ people to use the VPFX
in their code if they dont want to, but if the consensus is that
we should be pushing VPFX() usage, changing it is just stylistic.

--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
_______________________________________________
varnish-dev mailing list
varnish-dev@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev

Re: VMOD havoc generating patch [ In reply to ]

dridi at varni

Feb 5, 2019, 1:54 AM

Post #8 of 8 (1194 views)

Permalink

> >No, I mean when I look at the generated vcc_$VMOD_if.h, I see many
> >occurrences of the $Prefix that are not guarded by VPFX() macros.
>
> The VPFX/VARGS/VENUM macros are mostly intended as convenience for the
> files the vmod-author writes.

Ack.

> I didn't VPFX the prototypes to not _force_ people to use the VPFX
> in their code if they dont want to, but if the consensus is that
> we should be pushing VPFX() usage, changing it is just stylistic.

I will leave it to $Prefix users that need to support both 6.0 and the
new 6.2 vmodtool to leave an opinion here. I don't use the $Prefix
stanza.

Thanks,
Dridi
_______________________________________________
varnish-dev mailing list
varnish-dev@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev

Mailing List Archive

Mailing List Archive

Attached Files: