From per.buer at varnish-software.com Mon Apr 20 06:14:15 2026 From: per.buer at varnish-software.com (Per Buer) Date: Mon, 20 Apr 2026 08:14:15 +0200 Subject: Getting cross compilation to work. Message-ID: Hi. I have a suggestion. Currently, cross-compilation is broken. The biggest problem is the, imo overly clever use of RST (a formatting language) for data. During the build, the C code is compiled, which outputs RST used to build the documentation. How about moving this into a language made for data rather than formatting? So, with the data in JSON, the Python code will output C struct/array initializers for the binary to use at runtime as well as the RST consumed by the docs. The goal is easy cross-compilation. A bonus is that building a standalone configuration compiler would be easier if we ever wanna cross that bridge. -- Per Buer Varnish Software -------------- next part -------------- An HTML attachment was scrubbed... URL: From phk at phk.freebsd.dk Mon Apr 20 06:37:43 2026 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 20 Apr 2026 06:37:43 +0000 Subject: Getting cross compilation to work. In-Reply-To: References: Message-ID: <202604200637.63K6bhOi025966@critter.freebsd.dk> -------- Per Buer writes: > I have a suggestion. Currently, cross-compilation is broken. I wont say it is intentional, but considering that a C-compiler is required at runtime, cross-compilation seems somewhat pointless ? Which platforms are you thinking 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. From dridi at varni.sh Mon Apr 20 10:06:41 2026 From: dridi at varni.sh (Dridi Boukelmoune) Date: Mon, 20 Apr 2026 10:06:41 +0000 Subject: Getting cross compilation to work. In-Reply-To: References: Message-ID: On Mon, Apr 20, 2026 at 6:15?AM Per Buer wrote: > > Hi. > > I have a suggestion. Currently, cross-compilation is broken. The biggest problem is the, imo overly clever use of RST (a formatting language) for data. During the build, the C code is compiled, which outputs RST used to build the documentation. > > How about moving this into a language made for data rather than formatting? So, with the data in JSON, the Python code will output C struct/array initializers for the binary to use at runtime as well as the RST consumed by the docs. I would really prefer not to author JSON by hand, and the same goes for YAML. The advantage of generating code from the documentation is that we can literally "just write" documentation. As of today with reasonable formatting constraints like "Readable from:" etc in the vcl-var manual. Adding an indirection would trade a low pain point for a high one. Also, I think that for the most part codegen from RST is already done in Python: generate.py and vmodtool, plus vsctool and its pseudo-RST. Off the top of my head what we do with docs in C that requires running programs during the build is generating RST. So the solution would actually be to generate more C code from docs, going from docgen in C to codegen in Python. One example is the large params.h table that could be generated from RST code. > The goal is easy cross-compilation. A bonus is that building a standalone configuration compiler would be easier if we ever wanna cross that bridge. > > -- > Per Buer > Varnish Software > _______________________________________________ > vinyl-dev mailing list > vinyl-dev at vinyl-cache.org > https://vinyl-cache.org/lists/mailman/listinfo/vinyl-dev From phk at phk.freebsd.dk Mon Apr 20 10:19:22 2026 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 20 Apr 2026 10:19:22 +0000 Subject: Getting cross compilation to work. In-Reply-To: References: Message-ID: <202604201019.63KAJMFL026990@critter.freebsd.dk> -------- Dridi Boukelmoune writes: > Also, I think that for the most part codegen from RST is already done > in Python: generate.py and vmodtool, plus vsctool and its pseudo-RST. > > Off the top of my head what we do with docs in C that requires running > programs during the build is generating RST. So the solution would > actually be to generate more C code from docs, going from docgen in C > to codegen in Python. One example is the large params.h table that > could be generated from RST code. +1 -- 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. From per.buer at varnish-software.com Mon Apr 20 13:53:50 2026 From: per.buer at varnish-software.com (Per Buer) Date: Mon, 20 Apr 2026 15:53:50 +0200 Subject: Getting cross compilation to work. In-Reply-To: References: Message-ID: Hi, On Mon, Apr 20, 2026 at 12:07?PM Dridi Boukelmoune wrote: > On Mon, Apr 20: > > I would really prefer not to author JSON by hand, and the same goes > for YAML. The advantage of generating code from the documentation is > that we can literally "just write" documentation. As of today with > reasonable formatting constraints like "Readable from:" etc in the > vcl-var manual. Adding an indirection would trade a low pain point for > a high one. > Good point. I think we should just rework *vsl2rst.c* into *vsl2rst.py* and add a tbl_parse.py module that reads the X-macro files would solve the problem quite well. That would keep the C code as is, making it still the source of truth, but we'll avoid invoking just compiled binaries to generate the docs, as such skipping any cross-arch problems as python will do the same work on both host and target arch. Is a PR implementing this welcome? Per. -- Per Buer Varnish Software -------------- next part -------------- An HTML attachment was scrubbed... URL: From phk at phk.freebsd.dk Mon Apr 20 20:26:00 2026 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 20 Apr 2026 20:26:00 +0000 Subject: Getting cross compilation to work. In-Reply-To: References: Message-ID: <202604202026.63KKQ06T030304@critter.freebsd.dk> -------- Per Buer writes: > Is a PR implementing this welcome? Absolutely! -- 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. From per.buer at varnish-software.com Tue Apr 21 13:17:34 2026 From: per.buer at varnish-software.com (Per Buer) Date: Tue, 21 Apr 2026 15:17:34 +0200 Subject: Getting cross compilation to work. In-Reply-To: <202604202026.63KKQ06T030304@critter.freebsd.dk> References: <202604202026.63KKQ06T030304@critter.freebsd.dk> Message-ID: On Mon, Apr 20, 2026 at 10:26?PM Poul-Henning Kamp wrote: > -------- > Per Buer writes: > > > Is a PR implementing this welcome? > > Absolutely! > Fifteen places are affected by this. 14 of them are clean and easy to address. The last one is params.First, this requires significant work and complexity, and tackling it in Python will likely produce something quite fragile. So, I looked into autotools/CC_FOR_BUILD, which correctly creates an ad-hoc binary for the host, not the target. The problem is that "params.rst" will change if you are on 64-bit compiling for 32-bit, as the accepted arguments are somewhat different. Everything else will do fine. Do we still care about 32 bit? If we do this, it gets out of hand; if we don't care, it remains trivial. We still can't compile for other platforms, such as compiling on Linux for FreeBSD, because accept_filter and sysconf will differ. But arm64 <--> amd64 on the OS will work fine. -- Per Buer Varnish Software -------------- next part -------------- An HTML attachment was scrubbed... URL: From phk at phk.freebsd.dk Tue Apr 21 13:22:06 2026 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Tue, 21 Apr 2026 13:22:06 +0000 Subject: Getting cross compilation to work. In-Reply-To: References: <202604202026.63KKQ06T030304@critter.freebsd.dk> Message-ID: <202604211322.63LDM6YL015504@critter.freebsd.dk> -------- Per Buer writes: > Fifteen places are affected by this. 14 of them are clean and easy to > address. The last one is params.First, this requires significant work and > complexity, and tackling it in Python will likely produce something quite > fragile. Can you elaborate a bit on params.First and the resulting fragility ? I would like to understand the issue before we abandon the (IMO) better solultion ? -- 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. From per.buer at varnish-software.com Tue Apr 21 13:49:11 2026 From: per.buer at varnish-software.com (Per Buer) Date: Tue, 21 Apr 2026 15:49:11 +0200 Subject: Getting cross compilation to work. In-Reply-To: <202604211322.63LDM6YL015504@critter.freebsd.dk> References: <202604202026.63KKQ06T030304@critter.freebsd.dk> <202604211322.63LDM6YL015504@critter.freebsd.dk> Message-ID: On Tue, Apr 21, 2026 at 3:22?PM Poul-Henning Kamp wrote: > -------- > Per Buer writes: > > > > Fifteen places are affected by this. 14 of them are clean and easy to > > address. The last one is params.First, this requires significant work and > > complexity, and tackling it in Python will likely produce something quite > > fragile. > > Can you elaborate a bit on params.First and the resulting fragility ? > All the RST generation is quite easy to do in Python, except "params.rst", which leverages a lot of vinyl code like: #if defined(HAVE_ACCEPT_FILTERS) which will determine the final content of params.rst. Replicating this in Python sounds complex and fragile, likely requiring the replication of most of the C preprocessor. There is sysconf(_SC_THREAD_STACK_MIN) and MCF_ParamConf("thread_pools", "%d", MAX_THREAD_POOLS) which will affect params.rst will end up looking. So, autoconf has CC_FOR_BUILD, which allows us to use one compiler for the target and another for intermediate host tasks. This is a much smaller and simpler change than my original python suggestion, but it fails when you try to go FreeBSD <--> Linux or 64bit <--> 32bit, because the defaults change and the resulting params.rst will end up being somewhat off. Now, this is also possible to address by checking that the target OS is identical to the host OS and that the pointer size is the same in both places. So, I think, this is doable and will end up quite clean. If we want to support 64b->32b, we might have to add a "--disable-docs" for that to work. But personally, I would just deprecate 32b. It was a second class citizen i 2006 and is a bit of a joke today. -- Per Buer Varnish Software -------------- next part -------------- An HTML attachment was scrubbed... URL: From phk at phk.freebsd.dk Tue Apr 21 19:59:14 2026 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Tue, 21 Apr 2026 19:59:14 +0000 Subject: Getting cross compilation to work. In-Reply-To: References: <202604202026.63KKQ06T030304@critter.freebsd.dk> <202604211322.63LDM6YL015504@critter.freebsd.dk> Message-ID: <202604211959.63LJxEvE047783@critter.freebsd.dk> -------- Per Buer writes: > All the RST generation is quite easy to do in Python, except "params.rst", > which leverages a lot of vinyl code like: > > #if defined(HAVE_ACCEPT_FILTERS) So that kind is easy: It comes out of config.h and python can read that. An alternate take could be that we should always have the all the parameters, but their value might be a constant "N/A" if the parameter does not apply. (Not sure I have an opinion on that.) > There is sysconf(_SC_THREAD_STACK_MIN) and MCF_ParamConf("thread_pools", > "%d", MAX_THREAD_POOLS) which will affect params.rst will end up looking. So this is where it gets interesting. By definition the documentation cannot contain correct numerical values (min/max/default) for "dynamic" parameters. I know we stick 'examplary' numbers in the docs today, but that's more by accident of implementation than by intention. If I were starting over, I think I would prefer the doc to say "determined at runtime" rather than contain numbers which may or may not have anything to do with reality. Finally, of course, I think there are a parameters which serve no actual purpose (any longer) and can & ahould be removed. > So, autoconf has CC_FOR_BUILD, [...] I'm really not keen on wading deeper into the autocrap sump if we can avoid it. As to 32 bit: Yeah, those days have come and gone, and if I recall right we have already announced that 32bit would not be supported in this major release, and then, as we often do, forgot to actually remove it. Maybe we should start out with a "spring cleaning" and ditch 32bit for good and audit the parameters for any which are surplus to requirements. Poul-Henning PS: You have still not revealed why cross-building is important/desirable ? -- 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. From per.buer at varnish-software.com Wed Apr 22 06:24:32 2026 From: per.buer at varnish-software.com (Per Buer) Date: Wed, 22 Apr 2026 08:24:32 +0200 Subject: Getting cross compilation to work. In-Reply-To: <202604211959.63LJxEvE047783@critter.freebsd.dk> References: <202604202026.63KKQ06T030304@critter.freebsd.dk> <202604211322.63LDM6YL015504@critter.freebsd.dk> <202604211959.63LJxEvE047783@critter.freebsd.dk> Message-ID: On Tue, Apr 21, 2026 at 9:59?PM Poul-Henning Kamp wrote: > -------- > Per Buer writes: > > > There is sysconf(_SC_THREAD_STACK_MIN) and MCF_ParamConf("thread_pools", > > "%d", MAX_THREAD_POOLS) which will affect params.rst will end up looking. > > So this is where it gets interesting. > > By definition the documentation cannot contain correct numerical > values (min/max/default) for "dynamic" parameters. > > I know we stick 'examplary' numbers in the docs today, but that's > more by accident of implementation than by intention. > Right. One could argue there is a point in building man pages for a specific arch, but I'd rather there be just a single version of each man page and that the man pages match what is one the web. If I were starting over, I think I would prefer the doc to say > "determined at runtime" rather than contain numbers which may or > may not have anything to do with reality. > That is a reasonable stance. I agree. Finally, of course, I think there are a parameters which serve > no actual purpose (any longer) and can & ahould be removed. > So, autoconf has CC_FOR_BUILD, [...] > > I'm really not keen on wading deeper into the autocrap sump if we > can avoid it. > Reasonable. I got the CC trampoline it running last night, but autoconf's default error handling is pretty lame. You'll ask it for a cross-compile, it won't find the cross-compiler, and it will do a native compile instead, pretending everything is fine. You explicitly have to set up an assertion if you wanna be certain. We can't avoid that bit however, as we're already using it. The CC_FOR_BUILD stuff is pretty nice, actually. But having the docs be uniform is actually a better goal. As to 32 bit: > > Yeah, those days have come and gone, and if I recall right we have > already announced that 32bit would not be supported in this major > release, and then, as we often do, forgot to actually remove it. > > Maybe we should start out with a "spring cleaning" and ditch > 32bit for good and audit the parameters for any which are > surplus to requirements. > ok. Let's keep the scope somewhat limited, though. I'm not comfortable doing the audit, atm. PS: You have still not revealed why cross-building is important/desirable ? > Someone complained to me about the build system, so, I thought I'd have a look. ARM on the server-side is becoming increasingly important. It would be nice to not have to find ARM hardware or spin up QEMU to build ARM packages. Also, I find the current setup somewhat offensive. Pretty clever, though. -- Per Buer Varnish Software -------------- next part -------------- An HTML attachment was scrubbed... URL: From phk at phk.freebsd.dk Wed Apr 22 07:17:44 2026 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Wed, 22 Apr 2026 07:17:44 +0000 Subject: Getting cross compilation to work. In-Reply-To: References: <202604202026.63KKQ06T030304@critter.freebsd.dk> <202604211322.63LDM6YL015504@critter.freebsd.dk> <202604211959.63LJxEvE047783@critter.freebsd.dk> Message-ID: <202604220717.63M7HiPG014594@critter.freebsd.dk> -------- Per Buer writes: > Right. > > One could argue there is a point in building man pages for a specific arch, > but I'd rather there be just a single version of each man page and that the > man pages match what is one the web. I agree. I dont think we have ever made that an explicit decision, but as far as I can tell, we are already pretty close ? All platforms/archs/distros have the same set of parameters, and any inapplicable paramters have "#define PLATFORM_FLAGS NOT_IMPLEMENTED" which causes param.* CLI commands to "neuter" them, for instanc on (s390) linux: param.show accept_filter 200 137 accept_filter Not available [too many blank lines] NB: This parameter depends on a feature which is not available on this platform. But the documentation built on that same (s390) linux, has the same full spiel about that parameter, as the docs built on FreeBSD where accept_filter does work. So as far as I can tell, it is only dynamically determined aspects of the parameters (min/max/default) which vary between platforms and in the docs ? Have I overlooked something ? > If I were starting over, I think I would prefer the doc to say > > "determined at runtime" rather than contain numbers which may or > > may not have anything to do with reality. > > > > That is a reasonable stance. I agree. Anybody else want to chime in ? > Reasonable. I got the CC trampoline it running last night, but autoconf's > default error handling is pretty lame. Dont get me started... :-) > ARM on the server-side is becoming increasingly important. It would be nice to > not have to find ARM hardware or spin up QEMU to build ARM packages. We have had ARM covered on FreeBSD for ages, initially on a BBB (32bit) and RPi (64bit) but now on a QualCom "Snapdragon" based Thinkpad. So far nobody has bothered to set up a RPI with a USB disk to get linux covered in a similar fashion, even though all they have to do is run the tools/vco_test.sh script. (Nudge, nudge, wink, wink, he said knowingly!) :-) > Also, I find the current setup somewhat offensive. Pretty clever, though. The goal was to avoid redundancy, which could get out of sync, and considering how seldom we add or remove params, I'll claim that it worked. But yes: Not immediately obvious to the lay observer. -- 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. From dridi at varni.sh Wed Apr 22 08:09:32 2026 From: dridi at varni.sh (Dridi Boukelmoune) Date: Wed, 22 Apr 2026 08:09:32 +0000 Subject: Getting cross compilation to work. In-Reply-To: <202604220717.63M7HiPG014594@critter.freebsd.dk> References: <202604202026.63KKQ06T030304@critter.freebsd.dk> <202604211322.63LDM6YL015504@critter.freebsd.dk> <202604211959.63LJxEvE047783@critter.freebsd.dk> <202604220717.63M7HiPG014594@critter.freebsd.dk> Message-ID: On Wed, Apr 22, 2026 at 7:17?AM Poul-Henning Kamp wrote: > > -------- > Per Buer writes: > > > > Right. > > > > One could argue there is a point in building man pages for a specific arch, > > but I'd rather there be just a single version of each man page and that the > > man pages match what is one the web. > > I agree. > > I dont think we have ever made that an explicit decision, but as > far as I can tell, we are already pretty close ? > > All platforms/archs/distros have the same set of parameters, and any > inapplicable paramters have "#define PLATFORM_FLAGS NOT_IMPLEMENTED" which > causes param.* CLI commands to "neuter" them, for instanc on (s390) linux: > > param.show accept_filter > 200 137 > accept_filter > Not available > [too many blank lines] > NB: This parameter depends on a feature which is not available > on this platform. > > But the documentation built on that same (s390) linux, has the same > full spiel about that parameter, as the docs built on FreeBSD where > accept_filter does work. > > So as far as I can tell, it is only dynamically determined aspects of > the parameters (min/max/default) which vary between platforms and > in the docs ? > > Have I overlooked something ? > > > If I were starting over, I think I would prefer the doc to say > > > "determined at runtime" rather than contain numbers which may or > > > may not have anything to do with reality. > > > > > > > That is a reasonable stance. I agree. > > Anybody else want to chime in ? We should already generate the same manual for every architecture, maybe modulus 32 vs 64 bits. So that should already cover both "determined at runtime" but also "determined at configure time". With param.show we get the host-specific information as it is known at run time (including actual dynamic bounds). I see that the default value in the manual for vcl_path no longer shows "${sysconfdir}/varnish:${datadir}/varnish/vcl". And I see that the minimum value for thread_pool_max is no longer "thread_pool_min" in the manual. So it looks like a regression happened at some point, because the whole point of 3099 was to take care of that. https://github.com/varnishcache/varnish-cache/pull/3099 > > Reasonable. I got the CC trampoline it running last night, but autoconf's > > default error handling is pretty lame. > > Dont get me started... :-) > > > ARM on the server-side is becoming increasingly important. It would be nice to > > not have to find ARM hardware or spin up QEMU to build ARM packages. > > We have had ARM covered on FreeBSD for ages, initially on a BBB (32bit) > and RPi (64bit) but now on a QualCom "Snapdragon" based Thinkpad. > > So far nobody has bothered to set up a RPI with a USB disk to get > linux covered in a similar fashion, even though all they have to > do is run the tools/vco_test.sh script. > > (Nudge, nudge, wink, wink, he said knowingly!) :-) > > > Also, I find the current setup somewhat offensive. Pretty clever, though. > > The goal was to avoid redundancy, which could get out of sync, and > considering how seldom we add or remove params, I'll claim that it > worked. But yes: Not immediately obvious to the lay observer. > > -- > 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. From phk at phk.freebsd.dk Wed Apr 22 10:39:40 2026 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Wed, 22 Apr 2026 10:39:40 +0000 Subject: Getting cross compilation to work. In-Reply-To: References: <202604202026.63KKQ06T030304@critter.freebsd.dk> <202604211322.63LDM6YL015504@critter.freebsd.dk> <202604211959.63LJxEvE047783@critter.freebsd.dk> <202604220717.63M7HiPG014594@critter.freebsd.dk> Message-ID: <202604221039.63MAdeOr015465@critter.freebsd.dk> -------- Dridi Boukelmoune writes: > I see that the default value in the manual for vcl_path no longer > shows "${sysconfdir}/varnish:${datadir}/varnish/vcl". To be honest: How useful is that to people reading the manual ? Do they even have a way to determine where sysconfdir and datadir might be ? -- 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. From dridi at varni.sh Thu Apr 23 15:04:41 2026 From: dridi at varni.sh (Dridi Boukelmoune) Date: Thu, 23 Apr 2026 15:04:41 +0000 Subject: Getting cross compilation to work. In-Reply-To: <202604221039.63MAdeOr015465@critter.freebsd.dk> References: <202604202026.63KKQ06T030304@critter.freebsd.dk> <202604211322.63LDM6YL015504@critter.freebsd.dk> <202604211959.63LJxEvE047783@critter.freebsd.dk> <202604220717.63M7HiPG014594@critter.freebsd.dk> <202604221039.63MAdeOr015465@critter.freebsd.dk> Message-ID: On Wed, Apr 22, 2026 at 10:39?AM Poul-Henning Kamp wrote: > > -------- > Dridi Boukelmoune writes: > > > > I see that the default value in the manual for vcl_path no longer > > shows "${sysconfdir}/varnish:${datadir}/varnish/vcl". > > To be honest: How useful is that to people reading the manual ? > > Do they even have a way to determine where sysconfdir and datadir > might be ? Fair enough: https://github.com/varnish/varnish/pull/41 From dridi at varni.sh Thu Apr 23 15:09:35 2026 From: dridi at varni.sh (Dridi Boukelmoune) Date: Thu, 23 Apr 2026 15:09:35 +0000 Subject: Getting cross compilation to work. In-Reply-To: References: <202604202026.63KKQ06T030304@critter.freebsd.dk> <202604211322.63LDM6YL015504@critter.freebsd.dk> <202604211959.63LJxEvE047783@critter.freebsd.dk> <202604220717.63M7HiPG014594@critter.freebsd.dk> Message-ID: On Wed, Apr 22, 2026 at 8:09?AM Dridi Boukelmoune wrote: > > On Wed, Apr 22, 2026 at 7:17?AM Poul-Henning Kamp wrote: > > > > -------- > > Per Buer writes: > > > > > > > Right. > > > > > > One could argue there is a point in building man pages for a specific arch, > > > but I'd rather there be just a single version of each man page and that the > > > man pages match what is one the web. > > > > I agree. > > > > I dont think we have ever made that an explicit decision, but as > > far as I can tell, we are already pretty close ? > > > > All platforms/archs/distros have the same set of parameters, and any > > inapplicable paramters have "#define PLATFORM_FLAGS NOT_IMPLEMENTED" which > > causes param.* CLI commands to "neuter" them, for instanc on (s390) linux: > > > > param.show accept_filter > > 200 137 > > accept_filter > > Not available > > [too many blank lines] > > NB: This parameter depends on a feature which is not available > > on this platform. > > > > But the documentation built on that same (s390) linux, has the same > > full spiel about that parameter, as the docs built on FreeBSD where > > accept_filter does work. > > > > So as far as I can tell, it is only dynamically determined aspects of > > the parameters (min/max/default) which vary between platforms and > > in the docs ? > > > > Have I overlooked something ? > > > > > If I were starting over, I think I would prefer the doc to say > > > > "determined at runtime" rather than contain numbers which may or > > > > may not have anything to do with reality. > > > > > > > > > > That is a reasonable stance. I agree. > > > > Anybody else want to chime in ? > > We should already generate the same manual for every architecture, > maybe modulus 32 vs 64 bits. So that should already cover both > "determined at runtime" but also "determined at configure time". > > With param.show we get the host-specific information as it is known at > run time (including actual dynamic bounds). > > I see that the default value in the manual for vcl_path no longer > shows "${sysconfdir}/varnish:${datadir}/varnish/vcl". And I see that > the minimum value for thread_pool_max is no longer "thread_pool_min" > in the manual. So it looks like a regression happened at some point, > because the whole point of 3099 was to take care of that. > > https://github.com/varnishcache/varnish-cache/pull/3099 I had a quick look at 9.0 and the manual seems to render just fine. For example: > thread_pool_max > ? Units: threads > > ? Default: 5000 > > ? Minimum: thread_pool_min > > ? Flags: delayed Another example: > accept_filter > NB: This parameter depends on a feature which is not available on all platforms. > > ? Units: bool > > ? Default: on (if your platform supports accept filters) So this looks like a solved problem as far as generating the same (ish?) manual on all targets.