Re: Coverity Scan: Analysis completed for varnish

> I think Coverity Scan learned new tricks because nothing happened > since the last run: Indeed and I am going through them carefully as we speak. They are suprisingly tricky to decide... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since R

Re: gcc -fanalyze fyi

Nils Goroll writes: > *) https://social.treehouse.systems/@thesamesam/110697332121438807 Yes, that is precisely the top priority item for GCC I have pointed out for ages... Or maybe not... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP si

Re: Varnishtest client user agents

VTC-Client: c1 > > But also, since a VTC client mocks a user agent, I would rather use > the standard header for this. We can also add a -noua option similar > to -nolen, -nohost and -nodate and imply -noua when an explicit `-hdr > "User-Agent: other"` is present. So what

Re: Varnishtest client user agents

Dridi Boukelmoune writes: > On Wed, Jul 12, 2023 at 5:21=E2=80=AFAM Poul-Henning Kamp dk> wrote: > > > > > > Dridi Boukelmoune writes: > > > > > Would it be OK to have `client cNAME` send a `User-Agent: vtest > > > (cNAME)` or s

Re: Varnishtest client user agents

Dridi Boukelmoune writes: > Would it be OK to have `client cNAME` send a `User-Agent: vtest > (cNAME)` or similar to reduce some of it? I generally just use /c1 /c2 etc in the URL ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP sin

Re: Idea for multi-level CLI access control

Dridi Boukelmoune writes: > On Mon, Jun 26, 2023 at 6:39=E2=80=AFPM Poul-Henning Kamp dk> wrote: > > > Regarding the specific suggestion above, I don't think we would be > satisfied with this model. In the security barriers diagram [1] we > identified the followi

Idea for multi-level CLI access control

the 107 message so that the client can pick which secret file to use if it has access to multiple. * Varnishadm could look for secret files in ~/.varnish/${-i/-n arg} Comments ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer

a bit out of action....

I'm a bit out of action due to bacterial pneumonia, but I'll be keeping eye on things to the best of my ability. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what

Re: *.body VMOD arguments

.magic =TYPE_MAGIC, .name = "BODY", .noindent = 1, }}; -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Neve

Bugwash today at 15:00 EU time...

Can we please try to get the bugwash back on track ? If the monday 15:00 has become inconvenient for people we should try to find another and better timeslot. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer

Death on idea: filters on synth bodies

-- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@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 v

a possible micro-optimization

some kind of a performance test, I would be very interested to hear the results. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@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.

Working Group Last Call: HTTP Core Documents (fwd)

ady to progress. You can also file issues here: https://github.com/httpwg/http-core/issues <https://github.com/httpwg/http-core/issues>. Many thanks to Julian, Mark, and Roy for their hard work on editing these documents! Best, Tommy --- End Forwarded Message -- Poul-Henning Kamp

Re: allocating backend attributes to layers

oint layer. 'move' or 'also implement' ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@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. ___

allocating backend attributes to layers

et the limit at the Endpoint level. Maybe we need to be able to set limits both at the Backend and Endpoint levels ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what

VIP30 at todays bugwash

Please see: https://github.com/varnishcache/varnish-cache/wiki/VIP30%3A-Plumbing%3A-vcl_raw%28%29-and-vcl_pipe%28%29 Discussion in #3471 I'd like to get a preliminary go/no-go on the conceptual idea at bugwash today. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p

V-C.O upgrade footnotes

I have upgraded the V-C.O server to FreeBSD 12.2-RELEASE and it had some minor fallout: The 5.1, 5.2, 6.0 and 6.1 builds all failed in the automatic run, due to a new check in CLANG which spotted that a double cannot represent a LONG_MAX precisely. For 5.1 and 5.2, I patched a checked- out

2020-09-15 code freeze is lifted

Thanks to everybody, in particular Martin, for getting the 2020-09-15 release out the door. Code freeze is lifted, but please start gently. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never

Re: Making libunwind the default

reeBSD. Libunwind does not seem to support 32-bit Arm well, at least on FreeBSD. Would it make sense to make this a packaging decision ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe

Decide Name/number of 2020-09-15 release

We're going to nail the name/number of the 2020-09-15 release at the bugwash today. Please come prepared. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can

Starting to implement Cache-Status (fwd)

Anybody got time for some VCL hacking ? --- Forwarded Message From: Mark Nottingham Message-Id: <97385692-bff5-4fd2-a2eb-ec499182d...@mnot.net> Date: Thu, 6 Aug 2020 19:01:54 +1000 To: HTTP Working Group Subject: Starting to implement Cache-Status Just as a heads-up, we're starting to get

Re: Compared performance of Varnish Cache on x86_64 and aarch64

you want to get fancy, you can do a Student's T test to tell you if there is any real difference. There's a program called "ministat" which will do this for you. Also: I can highly recommend this book: http://www.larrygonick.com/titles/science/the-cartoon-guide-to-statistics/ -- Poul

VSB_quote has gotten messy

(), to be added shortly. Comments ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained

Summertime moves the bugwash!

For those participating in bugwash from outside the EU-hegemony: Please note that we europeans have moved to summertime now, so the bugwash at 1500 EU-time is now at 1300 UTC. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD

Re: Support for AARCH64

In message , Guillaume Quintard writes: >Offering arm64 packages requires a few things: Don't we have packages for a bunch of non-x86 architectures on Redhat ? I seem to recall Ingvar popping up with issues on s390 and other archs every so often ? -- Poul-Henning Kamp | U

Re: Support for AARCH64

Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@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 mailin

Code coverage by individual VTCs

-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@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

Re: changelog automation?

less commitlogs with the useful stuff omitted. The value of a changelog is *precisely* the editorial work which condenses the commitlog to a concise and useful document. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD

http-core status for IETF 106 (Singapore) (fwd)

Time to start reading... --- Forwarded Message From: "Roy T. Fielding" Date: Wed, 13 Nov 2019 12:03:27 -0800 To: "ietf-http...@w3.org Group" Subject: http-core status for IETF 106 (Singapore) > On Oct 25, 2019, at 3:00 PM, Tommy Pauly wrote: > > Our draft agenda for IETF 106 is

apology...

I should have been bug-washing, the machine was booting up. I promise to not make it a habit. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately

Re: #3093 proposed patch

In message , Martin Blix Grydeland writes: >But I do not think that this patch alone will be enough to fix #3093. My patch was only meant as a proof of concept for the "DTRT" part of the topic/discussion. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p..

#3093 proposed patch

etch{} ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@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. diff --git a/bin/varnishd/cache/cache.h b/bin/varnishd/cache/cac

Re: TLS sandboxing

ad. I can *possibly* be persuaded that we can handle session keys, and I will be perfectly happy to point at a 3rd party keyserver packages and say "that's where you get your keys from". -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC

Re: [varnishcache/varnish-cache] explicit_bzero() causing havoc (#3051)

l survive... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@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 mai

Re: [varnishcache/varnish-cache] explicit_bzero() causing havoc (#3051)

ution for wiping keys in memory, so one >hopes that it works most of the time. Ohh God! Now you just inspired all "cyberforces" to start implementing compiler optimizations... :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since R

VDD19Q3 wiki page

Please contribute: https://github.com/varnishcache/varnish-cache/wiki/VDD19Q3 -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained

Release 6.3 on next monday

ngineering. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@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 ma

Re: TLS sandboxing

uot;keyless" model. I'm hoping we can to raid the hitch source code to build the "keymaster" process. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice

VTLAM: VTEST -> VCI

During discussions with Nils yesterday it became clear that the overloading of "VTEST" for both the non-native version of varnishtest and for our CI setup is silly. To that end, I plan to rename the VTEST stuff to VCI as soon as a round tuit can be spared. -- Poul-Henning Kamp

Re: STRING_LIST deorbit burn completed

In message , Dridi Boukelmoune writes: >I found an old ASAT in my garage and STRING_LIST usage is now >gone from trunk. Thanks! -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3

a bit out of circulation

I managed to acquire an infected insect bite last week. Its nothing serious (the penicilin-stomach is worse), but it has reduced my bandwidth somewhat. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3

Re: STRING_LIST deorbit burn completed

In message , Dridi Boukelmoune writes: >On Fri, Jun 21, 2019 at 1:01 PM Poul-Henning Kamp wrote: >My point was rather that "all uses of STRING_LIST in the tree" aren't >removed yet: > >$ git grep STRING_LIST -- lib/libvmod_* >lib/libvmod_direct

Re: STRING_LIST deorbit burn completed

In message , Dridi Boukelmoune writes: >On Thu, Jun 20, 2019 at 9:29 AM Poul-Henning Kamp wrote: >> >> I have removed the remaining uses of STRING_LIST in the tree, and >> made vmodtool.py be slightly annoying if it is used. > >Not quite: Right now I'm tr

STRING_LIST deorbit burn completed

I have removed the remaining uses of STRING_LIST in the tree, and made vmodtool.py be slightly annoying if it is used. vmodtool.py will get more and more annoying about this over summer and around august 1st, it will refuse to compile it. The replacement is of course STRANDS. -- Poul-Henning

VCC now has type-driven properties

ow vmods to implement type driven properties and methods, but again: Convincing use cases ?. Proposals and ideas are welcome. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to

varnish gcov

bout stand out more. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@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. ___ v

Re: VIP23 (VSL refactoring) design sketch

the producer functions you can basically memcpy memcpy'ed the stack-frame into a network packet (or VSL record). This is horribly CPU-calling-convention specific, and needs special casing for strings, but in olden days before really smart compilers (ie: 68k) it was a pretty smart move. -- Poul-He

Re: VIP23 (VSL refactoring) design sketch

, without sinking in the "variable length integers" like the crap in OSI/X509/H2/H3 Of course Motorola had the benefit that neither zero nor minus 1 gives any meaning as relative jump displacement. We would probably want to sacrifice 0xfe rather than 0x00 (Benfords Law and all that) -- P

Re: on the vsl format - VIP23 (VSL refactoring) design sketch

nce we have switched over and the dust have settled, we can start to optimize field order. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be

Re: VIP23 (VSL refactoring) design sketch

-- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@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 lis

Re: VIP23 (VSL refactoring) design sketch

my laptop yesterday, and have not tought more about it. Can we conclude on this monday morning instead ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can a

Re: VIP23 (VSL refactoring) design sketch

dth. If they all call the same function, we do not. (Timestamp was a badly chosen example, because we already wrap that in a function call, but you get the idea...) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer |

Re: unused mailing lists

In message <593b2696-c8bf-f50d-ddde-84f4219d8...@schokola.de>, Nils Goroll writes: >I would have thought we already did exactly this. Ok, I wasn't sure. Never mind then. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 95

Re: VIP23 (VSL refactoring) design sketch

the arguments between VSL and presentation, so for instance timestamp could be serialized as: <8 byte double><8 byte double><8 byte double> So the VSLQ would always know where to find the doubles, but the presentation code in libvarnishapi would (still) render the string in

Re: unused mailing lists

In message <45384.1554798...@critter.freebsd.dk>, Poul-Henning Kamp writes: Also varnish-dist it seems. >It looks like varnish-test and varnish-bugs are not used anymore. > >Is it possible to configure so they reject any email sent, but the >archives still remain

unused mailing lists

It looks like varnish-test and varnish-bugs are not used anymore. Is it possible to configure so they reject any email sent, but the archives still remain visible in mailman ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD

Re: bugwash 2019-04-01

In message <8d34478b-e99a-2fe2-de43-f9a49ea27...@schokola.de>, Nils Goroll writes: >I will not be able to attend bugwash tomorrow I'm not sure I can either, I will be at Hamburg Hbf. most of that hour. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@fr

Re: 2019-03-15 release

In message , Dridi Boukelmoune writes: >On Thu, Mar 14, 2019 at 8:43 PM Poul-Henning Kamp wrote: >> >> Do not cut the release until I give the OK. >> >> I/We have a couple of i's to dots and t's to dash first. > >And coverity reported a bunch of things t

2019-03-15 release

Do not cut the release until I give the OK. I/We have a couple of i's to dots and t's to dash first. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can

Re: Doc updates on v-c.o

In message , Geoffrey Simmons wr ites: Seems like python3 fallout. should be fixed now -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can

code-freeze-ish

Trivial doc-commits and similar polishing allowed. Anything bigger than that needs an OK (PR/IRC) until the 15th. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what

Re: tabular CLI output proof of concept hack

libvarnish.a and expose it in libvarnishapi, >with a way for varnishadm to specify a window size in interactive >mode. This way varnishd -d will be able to produce the plain text >output. I think you need to unpack that a bit before I follow ? -- Poul-Henning Kamp | UNIX since

tabular CLI output proof of concept hack

Comments welcome... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@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. diff --git a/bin/varnishd/cache/cache_vcl.c b/bin/varn

Re: VMOD havoc generating patch

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 p...@freebsd.org | TCP/IP since R

Re: VMOD havoc generating patch

In message , Dridi Boukelmoune writes: >On Mon, Feb 4, 2019 at 8:30 PM Poul-Henning Kamp 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

Re: VMOD havoc generating patch

In message , Dridi Boukelmoune writes: >On Mon, Jan 28, 2019 at 1:55 PM Poul-Henning Kamp 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 fi

VMOD havoc generating patch

vmods for how this will look for you. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@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. diff --git a/doc/sphinx/reference

Re: vtest status

>with > make CC='gcc -O2 -s -D_GNU_SOURCE -DHAVE_SYS_VFS_H' > >we do not have anymore these warnings: Better ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribu

Re: vtest status

In message , Frederic Lecaille writes: >On 1/9/19 11:09 PM, Poul-Henning Kamp wrote: >> >> In message <1ca72b15-d581-4556-713a-a95106aa2...@haproxy.com>, Frederic >> Lecaille writes: >> >> Try the stuff I just committed. >> >>

Re: vtest status

e, you get varnish support. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@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: vtest status

es >to compile vtest this would help to its maintenance. Precisely. Watch out for a couple of commits... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute

Re: vtest status

u should call your compiled version something like "hatest", while we stick with "varnishtest", so we can reserve the "vtest" name for the future runtime-extensible all-singing-and-dancing thing ? Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20

Re: will be away Dec 11 - Jan 11

In message <04313569-1497-6243-7008-04b70024e...@schokola.de>, Nils Goroll writ es: >before I forget again to mention this during bugwash: > >I will be away for a month to experience Christmas during summer. .AU ? .NZ ? .ZA ? .AR ? -- Poul-Henning Kamp | UNIX s

Re: [6.1] 2f2387038 Fix gensequences for BusyBox awk

if (!l_prefix_name[n]) >- l_prefix_name[n] = "teken_state_" ++npr; >+ l_prefix_name[n] = "teken_state_" "" ++npr; > prefix = n; > } > >_______ >varnish

Fwd: Identifying our deliverables (naming QUIC's HTTP binding) (fwd)

As expected: QUIC == HTTP/3 Start reading up... Poul-Henning --- Forwarded Message From: Mark Nottingham Date: Tue, 30 Oct 2018 11:18:36 +1100 To: HTTP Working Group Message-Id: <67d04361-ce05-4dcc-aa99-3da259bbf...@mnot.net> Everyone, FYI, this might come to the WG in Bangkok.

Re: style(9), dir-locals.el and emacs-foo

k/emacs.html -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@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

Re: next VDD

to visit London before brexit, and a VDD could be an excuse to do so. Anywhere nort-europe-ish is fine with me. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to

Re: mini benchmark vtim formatting

simpler thing than the general FP formatting problem, but if there is any code I'm not keen on wading into, it is FP formatting code... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to ma

Re: mini benchmark vtim formatting

if we stick with double and simply by tweaking the formatting. Something like: printf("%ju.%06ju", (uint64_t)floor(foo), (uint64_t)floor((foo*1e6)) % 100UL); (Obviously to be hidden with PF-like macro) -- Poul-Henning Kamp | UNIX s

Re: Divorcing varnishtest from varnish-cache

I have made a first export/import of VTest now: https://github.com/vtest/VTest The Makefile is very rudimentary and mostly so that I could see that the convert.sh script does something sensible. Let the experiments start... Poul-Henning -- Poul-Henning Kamp | UNIX

Re: Divorcing varnishtest from varnish-cache

In message <20180924140433.68447...@barghest.suse.de>, Marcus =?UTF-8?B?UsO8Y2tlcnQ=?= writes: >On Sat, 22 Sep 2018 17:34:17 +0000 >"Poul-Henning Kamp" wrote: >> 4. No binary packages/releases will be built at this time >> >>HAproxy and V

Re: Divorcing varnishtest from varnish-cache

I guess my age is showing, as I almost forgot the most important thing: 0. We need a cute 'vtest' logo :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute

Re: Divorcing varnishtest from varnish-cache

In message <71064.1537637...@critter.freebsd.dk>, "Poul-Henning Kamp" writes: >1. Try to gain control of the empty 'vtest' account on github > I've sent them a message. (Do we know any insiders ?) > Alternative name suggestions if this fails are most welc

Divorcing varnishtest from varnish-cache

nish-Cache can/will import by whatever means from the new common 'vtest' project, and build vtest the way which works best for their project. (V-C obviously have some backwards compat issues) 5. See where that takes us. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd

Re: RFC: unify directors and backends vcl interface

In message , Nils Goroll writes: >On 19/09/2018 22:20, Poul-Henning Kamp wrote: >> One thing I *really* miss right now is some serious high-end >> benchmarking, to inform decisions about how much CPU we can afford >> to "waste" on stuff like this. >

Re: RFC: unify directors and backends vcl interface

ady for that yet. One thing I *really* miss right now is some serious high-end benchmarking, to inform decisions about how much CPU we can afford to "waste" on stuff like this. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 Fre

Absent from bugwash today...

I got out of bed at 03:45 and will not be present at bugwash today. Sorry. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained

Back in the saddle: Bugwash today at 13!

I'm back in the saddle and will attend bugwash today at 13 as usual. We have a load of tickets with bugwash label for today, so it would speed things up if people think about them before the bugwash. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since

Bugwash today: AWOL

I will be away from my keyboard at bugwash today. Regular attendance from next monday -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained

AWOL at bugwash today

I will not be present for bugwash today. Feel free to deal with any available laundry. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can

Re: CLI command vmod.tell

e done when a VMOD like xkey is targeted with a VCL pattern >matching more than once. You are entirely in control of what "arguments" are and how they are interpreted. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD commit

CLI command vmod.tell

gs when pattern is used so VMODs won't have to do that, or should they only be added in front of VMODs which produce cli output. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribu

Re: VDD summary

sible to say vmod.tell somevcl::somevmod "bla bla bla" To target a single one, but it is probably ill-advised to insist on always only targeting a single one. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD commi

Re: VDD summary

In message

VDD summary

s comments, reiterate, then PHK to review VRT_CTX, priv->free(), calls outside VCL methods (VDI) (and object destructors?) => This one sounds sensible, but requires some homework wrt. breaking APIs and if priv's need broken more (ie: dynamic objects) (again) native VCC type for regex

Re: backend/director admin states

ing state-machinery for directors... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by inc

Re: backend/director admin states

ble for formatting it, if required. As long as somebody who is not me writes the code for it... PS: We have a solid JSON parser in the tree already. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-

Re: backend/director admin states

In message

Re: backend/director admin states

In message <CAJ6ZYQx3vsFtWeTHpoU+ifgKjPDQv3=sH=c5q-zxfqjcu0k...@mail.gmail.com> , Guillaume Quintard writes: >All commands should have a JSON option, I reckon. Somebody should write more code for it then, I reckon :-) -- Poul-Henning Kamp | UNIX since Zilog Ze

Re: backend/director admin states

In message <1401d370-56dd-6006-2b3d-21771650f...@uplex.de>, Geoff Simmons write s: >>> Illustrated example: varnishadm backend.list output We should also think about varnishadm backend.list -j ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org

  1   2   3   4   5   >