Mailing List Archive

Christoph Schug <chris+varnish-misc at schug.net> writes:
> o PID file
> It would be very nice to have a PID file which can be used in some
> start/stop scripts. IMHO some killall(1) approch is not very nice,
> especially when running multiple instances of Varnish on the very same
> machine (e.g. release version and current SVN version).

Yes, that would be a good idea.

> o VCL code generation
> As far as I can see, lib/libvcl/vcc_compile.c just picks up some
> cc(1) for VCL code generation. As I have boxes with different C
> compilers installed I'm currently doing sed(1) substs at build
> time. Nevertheless I guess having a configurable path here would be
> benefical.

Ideally, this would be farmed out to a helper script to allow easy
modification of the compiler command and parameters.

DES
--
Dag-Erling Sm?rgrav
Senior Software Developer
Linpro AS - www.linpro.no

On Fri, Oct 13, 2006, Dag-Erling Sm?rgrav wrote:

> Christoph Schug <chris+varnish-misc at schug.net> writes:
> > o PID file
[...]
>
> Yes, that would be a good idea.

In the meantime I packaged Varnish as OpenPKG package using this patch
against 1.0.1 by setting -DOPKG_PIDFILE=/foo/bar/varnishd.pid in
CPPFLAGS. Not elegant, but works for me :)

Index: bin/varnishd/mgt_child.c
--- bin/varnishd/mgt_child.c.orig 2006-09-20 19:18:51 +0200
+++ bin/varnishd/mgt_child.c 2006-10-11 22:42:04 +0200
@@ -172,6 +172,21 @@

fprintf(stderr, "start child pid %d\n", i);

+#ifdef OPKG_PIDFILE
+ {
+ pid_t pid;
+ FILE *fp;
+
+ pid = getpid();
+ if ((fp = fopen(OPKG_PIDFILE, "w")) == NULL) {
+ fprintf(stderr, "varnishd:ERROR: cannot write PID file '%s'\n", OPKG_PIDFILE);
+ exit(1);
+ }
+ fprintf(fp, "%ld\n", (long)pid);
+ fclose(fp);
+ }
+#endif
+
AZ(close(child_fds[1]));
child_fds[1] = -1;

-cs

In message <ujririoy4w7.fsf at cat.linpro.no>, Dag-Erling =?iso-8859-1?Q?Sm=F8rgra
v?= writes:

>> o VCL code generation
>> As far as I can see, lib/libvcl/vcc_compile.c just picks up some
>> cc(1) for VCL code generation. As I have boxes with different C
>> compilers installed I'm currently doing sed(1) substs at build
>> time. Nevertheless I guess having a configurable path here would be
>> benefical.
>
>Ideally, this would be farmed out to a helper script to allow easy
>modification of the compiler command and parameters.

No, it should just be a parameter. We don't want to make
Varnish dependent on a lot of auxillary files.

--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk at 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.

"Poul-Henning Kamp" <phk at phk.freebsd.dk> writes:
> "Dag-Erling Sm?rgrav" <des at des.no> writes:
> > Ideally, this would be farmed out to a helper script to allow easy
> > modification of the compiler command and parameters.
> No, it should just be a parameter. We don't want to make
> Varnish dependent on a lot of auxillary files.

Some platforms may require more than a single command to produce a
loadable object; for instance, the object file generated by the
compiler may need processing with objcopy or ld or some similar tool.
Letting a helper script handle this is by far the easiest solution.

DES
--
Dag-Erling Sm?rgrav
Senior Software Developer
Linpro AS - www.linpro.no

In message <ujrfydsmkpe.fsf at cat.linpro.no>, Dag-Erling =?iso-8859-1?Q?Sm=F8rgra
v?= writes:
>"Poul-Henning Kamp" <phk at phk.freebsd.dk> writes:
>> "Dag-Erling Sm=F8rgrav" <des at des.no> writes:
>> > Ideally, this would be farmed out to a helper script to allow easy
>> > modification of the compiler command and parameters.
>> No, it should just be a parameter. We don't want to make
>> Varnish dependent on a lot of auxillary files.
>
>Some platforms may require more than a single command to produce a
>loadable object; for instance, the object file generated by the
>compiler may need processing with objcopy or ld or some similar tool.
>Letting a helper script handle this is by far the easiest solution.

Nothing you cannot do with a couple of semicolons and "sh -c $command"

I really really really do not want to see Varnish sprout a ton
of weird support files which people have to think about.

--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk at 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.

"Poul-Henning Kamp" <phk at phk.freebsd.dk> writes:
> I really really really do not want to see Varnish sprout a ton
> of weird support files which people have to think about.

Hopefully, the only person who needs to think about the compiler
helper script is the person doing the packaging for your favorite
distribution...

DES
--
Dag-Erling Sm?rgrav
Senior Software Developer
Linpro AS - www.linpro.no

On Fri, Oct 13, 2006, Dag-Erling Sm?rgrav wrote:

> "Poul-Henning Kamp" <phk at phk.freebsd.dk> writes:
> > I really really really do not want to see Varnish sprout a ton
> > of weird support files which people have to think about.
>
> Hopefully, the only person who needs to think about the compiler
> helper script is the person doing the packaging for your favorite
> distribution...

I don't see a difference, whether the program called is a real C
compiler or just a shell script which sorts out platform-specific stuff
(whoever this one likes to maintain). In case it is a user configurable
path with default to the current setting it simply doen't matter, does
it?

-cs

In message <20061013131508.GG30977 at voodoo.schug.net>, Christoph Schug writes:
>On Fri, Oct 13, 2006, Dag-Erling Sm?rgrav wrote:
>
>> "Poul-Henning Kamp" <phk at phk.freebsd.dk> writes:
>> > I really really really do not want to see Varnish sprout a ton
>> > of weird support files which people have to think about.
>>
>> Hopefully, the only person who needs to think about the compiler
>> helper script is the person doing the packaging for your favorite
>> distribution...
>
>I don't see a difference, whether the program called is a real C
>compiler or just a shell script which sorts out platform-specific stuff
>(whoever this one likes to maintain). In case it is a user configurable
>path with default to the current setting it simply doen't matter, does
>it?

One of the design goals of Varnish was "one single file". If you
have ever had an emergency at 2:05AM, you know that to be a very
important feature.

I have yet to see one single computer where the command to build a
shared object could not be encoded in a single command line and
therefore I see no reason to invalidate one of our goals for
that reason.

--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk at 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.

In message <ujrbqogmkdw.fsf at cat.linpro.no>, Dag-Erling =?iso-8859-1?Q?Sm=F8rgra
v?= writes:
>"Poul-Henning Kamp" <phk at phk.freebsd.dk> writes:
>> I really really really do not want to see Varnish sprout a ton
>> of weird support files which people have to think about.
>
>Hopefully, the only person who needs to think about the compiler
>helper script is the person doing the packaging for your favorite
>distribution...

As I said, we'll make the string a run time parameter, and if
people insist on polluting their system with pointless scripts,
that allows them to do so.

--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk at 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.

On Oct 13, 2006, at 3:23 PM, Poul-Henning Kamp wrote:

> One of the design goals of Varnish was "one single file". If you
> have ever had an emergency at 2:05AM, you know that to be a very
> important feature.

FWIW:

+1 (!!)

at any rate, version 1.0.2 doesn't seem like a good candidate to
break with that design goal already ;-)

>
> I have yet to see one single computer where the command to build a
> shared object could not be encoded in a single command line and
> therefore I see no reason to invalidate one of our goals for
> that reason.
>
> --
> Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
> phk at 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-misc mailing list
> varnish-misc at projects.linpro.no
> http://projects.linpro.no/mailman/listinfo/varnish-misc
>

On Fri, Oct 13, 2006, Poul-Henning Kamp wrote:

> I have yet to see one single computer where the command to build a
> shared object could not be encoded in a single command line and
> therefore I see no reason to invalidate one of our goals for
> that reason.

I fully agree with you. What I was trying to say, if we have a facility
to call user-defineable external commands, it simply doesn't matter
whether this command is single line command or a somewhat more complex
command, which itself calls 'cc', etc. As long as there's a safe
default, just everybody can stick with it. Those (like me) who'd like to
define some non-default value can shoot in their feet with every flavor
they want. One of the nice features of a swiss army knife is that you
can retract the blades before putting it the pocket. But you don't have
too ;-)

-cs