From martin at varnish-software.com Tue Nov 2 09:55:55 2010 From: martin at varnish-software.com (Martin Blix Grydeland) Date: Tue, 2 Nov 2010 10:55:55 +0100 Subject: Request for code review - add a flag to not auto-start child process for varnishd Message-ID: Hi Poul-Henning, Attached is a small patch to add a flag to varnishd that will make varnishd not auto-start the child process (much like what the -d flag does, but without the foreground CLI that the -d gives you). This is needed for running varnish in a managed setting using the -M option, and we would like to set the VCL and parameters through the CLI before varnish starts up. Regards, Martin Blix Grydeland -- Martin Blix Grydeland Varnish Software AS -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: X-flag.patch Type: application/octet-stream Size: 2534 bytes Desc: not available URL: From t_pascal at zennet.com Wed Nov 3 06:36:04 2010 From: t_pascal at zennet.com (T. Pascal) Date: Tue, 2 Nov 2010 23:36:04 -0700 Subject: Using results match in a rule Message-ID: Hello, we are attempting to block some useragents in Varnish and it works quite well, except we'd like to get some logging around that; the idea being: if (req.http.User-Agent ~ "(ua1|ua2|ua3") { error 403 "Forbidden UA $1"; } ...where $1 is the match part. This should be easy I would have thought? -T. From slink at schokola.de Wed Nov 3 09:25:25 2010 From: slink at schokola.de (Nils Goroll) Date: Wed, 03 Nov 2010 10:25:25 +0100 Subject: Using results match in a rule In-Reply-To: References: Message-ID: <4CD12A85.30102@schokola.de> > if (req.http.User-Agent ~ "(ua1|ua2|ua3") { > error 403 "Forbidden UA $1"; > } > > ...where $1 is the match part. This should be easy I would have thought? I have written code to do this, but it has not (yet) made it into Varnish, see: http://www.varnish-cache.org/trac/ticket/666 (call 666 for matchorchist) Nils From manoj.kumar at Xoriant.Com Tue Nov 2 10:26:43 2010 From: manoj.kumar at Xoriant.Com (Manoj Kumar) Date: Tue, 2 Nov 2010 15:56:43 +0530 Subject: VCl Rule Message-ID: Hi Team, I am working to use varnish with Mogiles but i have some problem. How can we check the file size in the varnish? because we want that if the file size is greater than 2 MB request will go to Varnish directly no to cache. I have tried some options but not able to find the solutions I tried req.url !~ "\.ogg$" && obj.size > 10MB vcl_prefetch() { if obj.http.Content-Length > xxxx { return(pipe); } } Please guide me, i am new to varnish. Also, Is there any way to debug the VCL rules because most of time if i add any rule, varnish is not start. Thanks Manoj -------------- next part -------------- An HTML attachment was scrubbed... URL: From slink at schokola.de Thu Nov 4 07:30:28 2010 From: slink at schokola.de (Nils Goroll) Date: Thu, 04 Nov 2010 08:30:28 +0100 Subject: syntax for back references In-Reply-To: <4CD12A85.30102@schokola.de> References: <4CD12A85.30102@schokola.de> Message-ID: <4CD26114.1060004@schokola.de> BTW, a couple of weeks ago, we were talking about syntax for the match back references on varnish-hacking. Actually something like the $n back-reference like in ... vv edited >> if (req.http.User-Agent ~ "(ua1|ua2|ua3)" { >> error 403 "Forbidden UA $1"; >> } ... should be quite easy to do in VCC IIUC - we'd only need to parse literal strings and take them apart into "literal", VRT_match(n), "literal". phk? Nils From slink at schokola.de Thu Nov 4 13:42:18 2010 From: slink at schokola.de (Nils Goroll) Date: Thu, 04 Nov 2010 14:42:18 +0100 Subject: Update [patch] use pthread_timedjoin_np() only where it exists In-Reply-To: <4CC2F47A.3010404@schokola.de> References: <4CC2F47A.3010404@schokola.de> Message-ID: <4CD2B83A.6000801@schokola.de> As of r5507, phk has added a new implementation for systems without pthread_timedjoin_np. Here's a one-liner to make it actually kill the test thread upon timeout -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: varnish_pthread_timedjoin_np.patch URL: From slink at schokola.de Thu Nov 4 19:27:07 2010 From: slink at schokola.de (Nils Goroll) Date: Thu, 04 Nov 2010 20:27:07 +0100 Subject: [patch] [experimental] release unneeded graced objects Message-ID: <4CD3090B.1090307@schokola.de> Hi, I've written a patch for something which has annoyed me for long: It's nice to have a really long grace period, such that even when all backend servers go down, Varnish can keep most of a website up. But setting a (really) long grace period (to catch most of the long tail) will mean that expiry by TTL (object time_when = ttl + grace, actually) will effectively be disabled and objects will get nuked by LRU only (mostly). varnishstat figures for such a configuration might look like this: 3451931 . . N expired objects 239097244 . . N LRU nuked objects 1059383291 . . N LRU moved objects Even more importantly, the cache will contain many copies of each object, so it will become unnecessarily huge (at least until the backend refresh implementation is done, which we're working on). I am not using -spersistent so I can't tell from own experience, but with persistent storage, using a long grace time will probably be unfeasible. The attached patch basically shuffles some of phk's code around in cache_hash.c (I guess I might have written half a dozen lines myself :) ) to collect unneeded graced objects while looking for a graced object. All graced objects older than the youngest (which also match the other criteria (think Vary)) will get released. This should dramatically reduce the effective cache size on systems with long grace, bring up the expired / nuked ratio, and speed up cache lookup, because the object list hanging off head object head should shrink significantly. The additional code will only kick in when a graced object needs to be looked up, so it should not lower efficiency for the standard case. But still it think a better place for this might be somewhen after inserting an object into the cache. The patch passes all tests, but I HAVE NOT TESTED IT IN PRODUCTION. Be warned. Any feedback from pre-production or production tests is more than welcome. Thanks, Nils -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: varnish.release_unneeded_objects_in_grace.patch URL: From slink at schokola.de Fri Nov 5 15:32:56 2010 From: slink at schokola.de (Nils Goroll) Date: Fri, 05 Nov 2010 16:32:56 +0100 Subject: [patch] vtc: scale timeout constants with npar Message-ID: <4CD423A8.5030909@schokola.de> Hi, phk has added parallelism to varnishtest, which is cool for those of us who live on larger SMPs (-j option). Running first tests with -j, I noticed that some hardcoded timeouts expire much more easily when fully loading a machine, so as a first, very simplistic approach, I've changed those timeout to scale with the number of parallel jobs. But timeouts in varnishtest will probably need to be revisited. Nils -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: vtc_scale_timeout_constants_with_npar.patch URL: From jbq at caraldi.com Mon Nov 8 16:11:56 2010 From: jbq at caraldi.com (Jean-Baptiste Quenot) Date: Mon, 8 Nov 2010 17:11:56 +0100 Subject: Size of GET URI? Message-ID: Hi there, I'm using Varnish 2.0.6 on Ubuntu, and wonder why my GET URIs are truncated to 256 bytes in the output of varnishlog and varnishncsa? Is it possible to tune this? Thanks in advance, -- Jean-Baptiste Quenot From slink at schokola.de Tue Nov 9 17:10:49 2010 From: slink at schokola.de (Nils Goroll) Date: Tue, 09 Nov 2010 18:10:49 +0100 Subject: [patch] "is set" / "is unset" expect tests for varnishtest Message-ID: <4CD98099.8040907@schokola.de> I've written the attached patch becuase I thought I needed something like expect resp.http.foo is set or expect resp.http.bar is unset in vtc. It turned out that I don't need it, but maybe others will find this useful. Nils -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: vtc_is_set_unset.patch URL: From slink at schokola.de Tue Nov 9 17:13:28 2010 From: slink at schokola.de (Nils Goroll) Date: Tue, 09 Nov 2010 18:13:28 +0100 Subject: [patch] beresp.pass and obj.pass for VCL Message-ID: <4CD98138.8050905@schokola.de> The attached patch will add read-only access to these new variables which indicate if the backend response or object originated from a pass request. See vcl.rst for more details. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: obj_beresp.pass.patch URL: From sanjoy at playingwithpointers.com Wed Nov 10 06:55:54 2010 From: sanjoy at playingwithpointers.com (Sanjoy Das) Date: Wed, 10 Nov 2010 12:25:54 +0530 Subject: [PATCH] fileread for the std VMOD Message-ID: Hi All! I've been toying around with Varnish's source for some time and have been looking for small tasks to get me started with the same. With PHK's suggestion, I've implemented a small addition to the std VMOD which reads (and caches) a file. I've attached the patch (fileread-std-vmod.diff) for review. Once applied, it should allow VCL to do things like set resp.http.Some-Header = std.fileread("/tmp/foo"); It loads and caches the contents of "/tmp/foo" in memory and returns the same; refreshing it whenever the file changes on disk. While working on the above I ran into a small problem with the import statement - VCC does not seem to like `import std': ''' Message from VCC-compiler: Could not load module std XXX: XXX: no default path XXX: XXX: no default path: cannot open shared object file: No such file or directory ('input' Line 1 Pos 8) import std; -------###- Running VCC-compiler failed, exit 1 ''' I fixed this by having VCC (I know that I may be way off on this one): i. Load libvmod_std.so automagically for `import std;' ii. Requiring something like `import foo "mysuperdupersharedobject.so";' for other VMODs. iii. Allow the same convention (ii) for std as well. This is done by the other patch I've attached (vmod-load-so.diff). Once applied, it makes VCC accept any of the following: import std; /* dlopen libvmod_std.so as std automatically */ import std "some_other_std.so"; /* dlopen some_other_std.so as std */ import foo "foo.so"; /* dlopen foo.so and use it as VMOD foo */ Both patches are diffs against SVN revision 5531. -- Regards, Sanjoy Das. http://playingwithpointers.com Public Key at http://playingwithpointers.com/custom/public_key.txt -------------- next part -------------- A non-text attachment was scrubbed... Name: vmod-load-so.diff Type: text/x-patch Size: 966 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: fileread-std-vmod.diff Type: text/x-patch Size: 3216 bytes Desc: not available URL: From phk at phk.freebsd.dk Wed Nov 10 09:46:44 2010 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Wed, 10 Nov 2010 09:46:44 +0000 Subject: [PATCH] fileread for the std VMOD In-Reply-To: Your message of "Wed, 10 Nov 2010 12:25:54 +0530." Message-ID: <55380.1289382404@critter.freebsd.dk> In message , Sanj oy Das writes: >I've attached the patch >(fileread-std-vmod.diff) for review. Will look. >While working on the above I ran into a small problem with the import >statement - VCC does not seem to like `import std': > >''' >Message from VCC-compiler: >Could not load module std The "XXX" means that I need to corner Tollef, to settle the technicalities around the default vmod directory. You just have to specify the path as 3rd. argument for now: import std "/some/where/libvmod.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. From sanjoy at playingwithpointers.com Thu Nov 11 13:12:50 2010 From: sanjoy at playingwithpointers.com (Sanjoy Das) Date: Thu, 11 Nov 2010 18:42:50 +0530 Subject: [PATCH] fileread for the std VMOD In-Reply-To: <55417.1289382917@critter.freebsd.dk> References: <55417.1289382917@critter.freebsd.dk> Message-ID: Hi! I've attached a new patch implementing fileread with the required corrections (std-vmod-fileread.diff) and a patch implementing a basic test-case (fileread-test-case.diff) - I am still figuring out how to properly write a real multi-threaded stress-test. There are a few issues, however. Firstly, since the file is being mmaped, files whose sizes are exact multiples of the system page size will cause a segmentation fault. This is a direct consequence of the fact that VCL strings are null terminated - unless there is some (zeroed, by POSIX) space _left over_ due to a non-aligned file-size, code that tries to read the string will end up trying to access a non-mapped memory location. As I see it (from within the confines of my limited experience :) ), there are three ways by which this can be corrected: i. Don't process files with sizes which are evenly divided by the system page size. This is what is done now. This really does not solve anything. ii. Open file, copy to memory, close file. This may be too inefficient, but this solves the second problem as well (mentioned below). iii. Instead of representing VCL strings as regular null-terminated C strings, store the length somewhere; perhaps by representing them as a struct containing a pointer to a character array and a length. When required (for passing them to standard library functions, for instance), they can be trivially converted to a regular C string, by copying. The second issue is that of the file changing after it has been mmapped. While on Linux it seems that the changes are reflected back to mmaped memory block, this is not a scenario well defined by POSIX. Even in Linux, we're in trouble if a file which was not originally of a length evenly divisible by the page size becomes so due to the addition of text. One solution, as I see it, would be to add another function, calling it filerefresh, which remaps (with the new length) the file whose file-name is passed, possibly after doing a timestamp check. This effectively leaves it to the VCL writer to decide which files may change, and which may not. -- Regards, Sanjoy Das. http://playingwithpointers.com Public Key at http://playingwithpointers.com/custom/public_key.txt -------------- next part -------------- A non-text attachment was scrubbed... Name: fileread-test-case.diff Type: text/x-patch Size: 786 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: std-vmod-fileread.diff Type: text/x-patch Size: 4285 bytes Desc: not available URL: From jbq at caraldi.com Thu Nov 11 13:21:02 2010 From: jbq at caraldi.com (Jean-Baptiste Quenot) Date: Thu, 11 Nov 2010 14:21:02 +0100 Subject: Size of GET URI? In-Reply-To: References: Message-ID: I finally found the shm_reclen setting by issuing a "git grep truncate" in the source code :-) And it lead me to this ticket http://www.varnish-cache.org/trac/ticket/528 I added "-p shm_reclen=65535" to the command line, it works as expected. Cheers, -- Jean-Baptiste Quenot From hefengcui at gmail.com Sun Nov 14 03:52:41 2010 From: hefengcui at gmail.com (hefeng cui) Date: Sun, 14 Nov 2010 11:52:41 +0800 Subject: How to retrieve time stamp of ReqStart and ReqEnd from share memory Message-ID: Hi, I want to write my own log generator by extending the varnishncsa. Currently I met a road blocker : how to retrieve the time stamp information of ReqStart and ReqEnd? I want to get the same information of like using the following command line: varnishlog -c -i RxURL -i Length -i ReqEnd 11 RxURL c / 11 Length c 192 11 ReqEnd c 1648285752 1289568283.914762497 1289568284.574348450 0.000066519 0.659481525 0.000104427 Any suggestion or code snippet would be highly appreciated! Best regards, Hefeng -------------- next part -------------- An HTML attachment was scrubbed... URL: From sanjoy at playingwithpointers.com Mon Nov 15 08:48:23 2010 From: sanjoy at playingwithpointers.com (Sanjoy Das) Date: Mon, 15 Nov 2010 14:18:23 +0530 Subject: [PATCH] fileread for the std VMOD In-Reply-To: References: <55417.1289382917@critter.freebsd.dk> Message-ID: Hi! Here's an implementation which uses malloc instead of mmap (and hence bypasses both the issues altogether); and a more rigorous testcase. -- Regards, Sanjoy Das. http://playingwithpointers.com Public Key at http://playingwithpointers.com/custom/public_key.txt -------------- next part -------------- A non-text attachment was scrubbed... Name: fileread-vmod-malloc.patch Type: text/x-patch Size: 4120 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: fileread-testcase.patch Type: text/x-patch Size: 2770 bytes Desc: not available URL: From tfheen at varnish-software.com Tue Nov 16 13:37:36 2010 From: tfheen at varnish-software.com (Tollef Fog Heen) Date: Tue, 16 Nov 2010 14:37:36 +0100 Subject: [PATCH] fileread for the std VMOD In-Reply-To: <55380.1289382404@critter.freebsd.dk> (Poul-Henning Kamp's message of "Wed, 10 Nov 2010 09:46:44 +0000") References: <55380.1289382404@critter.freebsd.dk> Message-ID: <87aal92xun.fsf@qurzaw.linpro.no> ]] "Poul-Henning Kamp" | The "XXX" means that I need to corner Tollef, to settle the technicalities | around the default vmod directory. I think just using pkglibdir/vmods is fine, that'll typically be /usr/lib/varnish/vmods which looks like a reasonable place for it. If you agree with this, I'm happy enough to write up a patch. -- Tollef Fog Heen Varnish Software t: +47 21 98 62 64 From tfheen at varnish-software.com Tue Nov 16 13:38:31 2010 From: tfheen at varnish-software.com (Tollef Fog Heen) Date: Tue, 16 Nov 2010 14:38:31 +0100 Subject: How to retrieve time stamp of ReqStart and ReqEnd from share memory In-Reply-To: (hefeng cui's message of "Sun, 14 Nov 2010 11:52:41 +0800") References: Message-ID: <8762vx2xt4.fsf@qurzaw.linpro.no> ]] hefeng cui | I want to write my own log generator by extending the varnishncsa. | Currently I met a road blocker : how to retrieve the time stamp information | of ReqStart and ReqEnd? Use sscanf on the string in the varnishncsa state machine. -- Tollef Fog Heen Varnish Software t: +47 21 98 62 64 From tfheen at varnish-software.com Tue Nov 16 13:41:32 2010 From: tfheen at varnish-software.com (Tollef Fog Heen) Date: Tue, 16 Nov 2010 14:41:32 +0100 Subject: Virtualhost logging for varnishncsa In-Reply-To: (Rob Halff's message of "Tue, 7 Apr 2009 10:50:34 +0200") References: Message-ID: <871v6l2xo3.fsf@qurzaw.linpro.no> ]] Rob Halff Hi, Ancient mail, I know. | Can I draw the conclusing, from the overwhelming response, that nobody | is really interested in this patch ? :-) I've implemented user-specifiable formats for varnishncsa in trunk now, please test that and see if it works for you? Regards, -- Tollef Fog Heen Varnish Software t: +47 21 98 62 64 From rob.halff at gmail.com Tue Nov 16 14:10:41 2010 From: rob.halff at gmail.com (Rob Halff) Date: Tue, 16 Nov 2010 15:10:41 +0100 Subject: Virtualhost logging for varnishncsa In-Reply-To: <871v6l2xo3.fsf@qurzaw.linpro.no> References: <871v6l2xo3.fsf@qurzaw.linpro.no> Message-ID: Hi Tollef, Thanks for implementing a proper solution. I will try it as soon as possible, although my currently running varnish version still dates from the time I've made that post, so I'll have some more updating to do :-) Greetings, Rob Halff On Tue, Nov 16, 2010 at 2:41 PM, Tollef Fog Heen wrote: > ]] Rob Halff > > Hi, > > Ancient mail, I know. > > | Can I draw the conclusing, from the overwhelming response, that nobody > | is really interested in this patch ? :-) > > I've implemented user-specifiable formats for varnishncsa in trunk now, > please test that and see if it works for you? > > Regards, > -- > Tollef Fog Heen > Varnish Software > t: +47 21 98 62 64 > From hefengcui at gmail.com Wed Nov 17 14:39:08 2010 From: hefengcui at gmail.com (hefeng cui) Date: Wed, 17 Nov 2010 22:39:08 +0800 Subject: How to retrieve time stamp of ReqStart and ReqEnd from share memory In-Reply-To: <8762vx2xt4.fsf@qurzaw.linpro.no> References: <8762vx2xt4.fsf@qurzaw.linpro.no> Message-ID: Hi Tollef Fog Heen, Thanks a lot for your reply! I used same way extracted ReqStart Time and Complete Time from ReqEnd Tag's log entry. Best regards, Hefeng On Tue, Nov 16, 2010 at 9:38 PM, Tollef Fog Heen < tfheen at varnish-software.com> wrote: > ]] hefeng cui > > | I want to write my own log generator by extending the varnishncsa. > | Currently I met a road blocker : how to retrieve the time stamp > information > | of ReqStart and ReqEnd? > > Use sscanf on the string in the varnishncsa state machine. > > -- > Tollef Fog Heen > Varnish Software > t: +47 21 98 62 64 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From phk at phk.freebsd.dk Thu Nov 18 22:16:49 2010 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Thu, 18 Nov 2010 22:16:49 +0000 Subject: [PATCH] fileread for the std VMOD In-Reply-To: Your message of "Tue, 16 Nov 2010 14:37:36 +0100." <87aal92xun.fsf@qurzaw.linpro.no> Message-ID: <7532.1290118609@critter.freebsd.dk> In message <87aal92xun.fsf at qurzaw.linpro.no>, Tollef Fog Heen writes: >]] "Poul-Henning Kamp" > >| The "XXX" means that I need to corner Tollef, to settle the technicalities >| around the default vmod directory. > >I think just using pkglibdir/vmods is fine, that'll typically be >/usr/lib/varnish/vmods which looks like a reasonable place for it. > >If you agree with this, I'm happy enough to write up a patch. Please do. -- 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 tfheen at varnish-software.com Fri Nov 19 06:52:05 2010 From: tfheen at varnish-software.com (Tollef Fog Heen) Date: Fri, 19 Nov 2010 07:52:05 +0100 Subject: [PATCH] fileread for the std VMOD In-Reply-To: <7532.1290118609@critter.freebsd.dk> (Poul-Henning Kamp's message of "Thu, 18 Nov 2010 22:16:49 +0000") References: <7532.1290118609@critter.freebsd.dk> Message-ID: <8762vtx0tm.fsf@qurzaw.linpro.no> ]] "Poul-Henning Kamp" | Please do. It was already set to pkglibdir, so I just adjusted that to pkglibdir/vmods and exposed that in the pkg-config file. I don't think we want to promote this to a configure option, people shouldn't need to move those things around. -- Tollef Fog Heen Varnish Software t: +47 21 98 62 64 From phk at phk.freebsd.dk Fri Nov 19 10:03:31 2010 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Fri, 19 Nov 2010 10:03:31 +0000 Subject: [PATCH] fileread for the std VMOD In-Reply-To: Your message of "Fri, 19 Nov 2010 07:52:05 +0100." <8762vtx0tm.fsf@qurzaw.linpro.no> Message-ID: <3764.1290161011@critter.freebsd.dk> In message <8762vtx0tm.fsf at qurzaw.linpro.no>, Tollef Fog Heen writes: >]] "Poul-Henning Kamp" > >| Please do. > >It was already set to pkglibdir, so I just adjusted that to >pkglibdir/vmods and exposed that in the pkg-config file. I don't think >we want to promote this to a configure option, people shouldn't need to >move those things around. If they want to move it, there is a runtime param they can set. -- 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 Tue Nov 23 08:41:33 2010 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Tue, 23 Nov 2010 08:41:33 +0000 Subject: [PATCH] fileread for the std VMOD In-Reply-To: Your message of "Mon, 15 Nov 2010 14:18:23 +0530." Message-ID: <2349.1290501693@critter.freebsd.dk> In message , Sanj oy Das writes: >Here's an implementation which uses malloc instead of mmap (and hence >bypasses both the issues altogether); and a more rigorous testcase. Yes, that is a better solution. Can I get you to put fileread into a separate source file ? It is sufficiently complex for that. Some nits from FlexeLint: ../../lib/libvmod_std/vmod_std.c 288 Warning 529: Symbol 'aligned_sz' (line 207) not subsequently referenced ../../lib/libvmod_std/vmod_std.c 207 Info 830: Location cited in prior message (Use the autogen.des script to get developer settings and GCC would have told you this) ../../lib/libvmod_std/vmod_std.c 288 Warning 550: Symbol 'pagesize' (line 207) not accessed ../../lib/libvmod_std/vmod_std.c 207 Info 830: Location cited in prior message pthread_rwlock_unlock(&filelist_lock); ../../lib/libvmod_std/vmod_std.c 245 Warning 534: Ignoring return value of function 'pthread_rwlock_unlock(struct pthread_rwlock **)' (compare with line 234, file /usr/include/pthread.h, module cache_acceptor.c) /usr/include/pthread.h 234 Info 830: Location cited in prior message _ fstat(fd, &buf); ../../lib/libvmod_std/vmod_std.c 250 Warning 534: Ignoring return value of function 'fstat(int, struct stat *)' (compare with line 307, file /usr/include/sys/stat.h, module mgt_param.c) /usr/include/sys/stat.h 307 Info 830: Location cited in prior message ALLOC_OBJ(iter, CACHED_FILE_MAGIC); >> missing assert check here iter->file_name = strdup(file_name); close(fd); ../../lib/libvmod_std/vmod_std.c 278 Warning 534: Ignoring return value of function 'close(int)' (compare with line 324, file /usr/include/unistd.h, module cache_acceptor.c) /usr/include/unistd.h 324 Info 830: Location cited in prior message (Put an AZ() on it, We are _very_ paranoid about fd-usage in varnish) +Info 765: external 'filelist_lock' (line 198, file ../../lib/libvmod_std/vmod_s td.c) + could be made static +../../lib/libvmod_std/vmod_std.c 198 Info 830: Location cited in prior + message +Info 765: external 'filelist_update' (line 199, file ../../lib/libvmod_std/vmod _std.c) + could be made static +../../lib/libvmod_std/vmod_std.c 199 Info 830: Location cited in prior + message +Info 843: Variable 'filelist_update' (line 199, file ../../lib/libvmod_std/vmod _std.c) + could be declared as const +../../lib/libvmod_std/vmod_std.c 199 Info 830: Location cited in prior + message -- 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 sanjoy at playingwithpointers.com Wed Nov 24 07:01:38 2010 From: sanjoy at playingwithpointers.com (Sanjoy Das) Date: Wed, 24 Nov 2010 12:31:38 +0530 Subject: [PATCH] fileread for the std VMOD In-Reply-To: <2349.1290501693@critter.freebsd.dk> References: <2349.1290501693@critter.freebsd.dk> Message-ID: Hi! > Can I get you to put fileread into a separate source file ? ?It is > sufficiently complex for that. Done. > > Some nits from FlexeLint: > > ../../lib/libvmod_std/vmod_std.c ?288 ?Warning 529: Symbol 'aligned_sz' (line > ? ?207) not subsequently referenced > ../../lib/libvmod_std/vmod_std.c ?207 ?Info 830: Location cited in prior > ? ?message > > (Use the autogen.des script to get developer settings and GCC would have > told you this) Sorry; was not aware. The patch now builds without error with the Makefiles generated by autogen.des. -- Regards, Sanjoy Das. http://playingwithpointers.com Public Key at http://playingwithpointers.com/custom/public_key.txt -------------- next part -------------- A non-text attachment was scrubbed... Name: vmod-fileread.patch Type: text/x-patch Size: 4614 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: vmod-fileread-testcase-patch.patch Type: text/x-patch Size: 2770 bytes Desc: not available URL: From sanjoy at playingwithpointers.com Fri Nov 26 17:02:52 2010 From: sanjoy at playingwithpointers.com (Sanjoy Das) Date: Fri, 26 Nov 2010 22:32:52 +0530 Subject: [PATCH] fileread for the std VMOD In-Reply-To: References: <2349.1290501693@critter.freebsd.dk> Message-ID: Hi! Have attached the patch for vmod_std_fileread.c, now prepended with the license as required. -- Regards, Sanjoy Das. http://playingwithpointers.com Public Key at http://playingwithpointers.com/custom/public_key.txt -------------- next part -------------- A non-text attachment was scrubbed... Name: vmod-fileread.patch Type: text/x-patch Size: 6048 bytes Desc: not available URL: From sanjoy at playingwithpointers.com Tue Nov 30 06:23:38 2010 From: sanjoy at playingwithpointers.com (Sanjoy Das) Date: Tue, 30 Nov 2010 11:53:38 +0530 Subject: [PATCH] fileread for the std VMOD In-Reply-To: References: Message-ID: <1291098218.2374.10.camel@DivineComedy> Hi! Attached patches make fileread's loaded-file cache a global list. I'm currently working on implementing (preferably lockless) reference counting (and then I'll have the call-private pointer point to a node in the global list; with proper cleanup). What do I use for a CAS? I've been using __sync_val_compare_and_swap; but that's GCC specific. -- Regards, Sanjoy Das http://playingwithpointers.com http://playingwithpointers.com/custom/public_key.txt -------------- next part -------------- A non-text attachment was scrubbed... Name: global-lists.patch Type: text/x-patch Size: 5358 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: structuring.patch Type: text/x-patch Size: 4892 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: