Btw, Nico, that rabin hash code is _extremely_ confusing. The hash entry pointers point to "data + RABIN_WINDOW", and then to make things even _more_ confusing, the hash calculation code is actually offset by one, so it will have computed the hash with val = ((val << 8) | data[i]) ^ T[val >> RABIN_SHIFT]; where "i" goes from _1_ to RABIN_WINDOW instead of 0..WINDOW-1. So, if I read that correctly, the "entry->ptr" actually points not to the beginning of the data that was hashed, or even the end, but literally to the last byte of the data that was hashed in that window. Isn't that just _really_ confusing? Or is there some sense to this? Linus - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Greg Kroah-Hartman | [PATCH 006/196] Chinese: add translation of oops-tracing.txt |
| Eric Sandeen | Re: [RFC] Heads up on sys_fallocate() |
| YOSHIFUJI Hideaki / | request_module: runaway loop modprobe net-pf-1 (is Re: Linux 2.6.21-rc1) |
git: | |
| Gerrit Renker | [PATCH 0/37] dccp: Feature negotiation - last call for comments |
| Jarek Poplawski | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Ben Greear | Re: MACVLANs really best solution? How about a bridge with multiple bridge virtual... |
| Rafael J. Wysocki | 2.6.29-rc8: Reported regressions from 2.6.28 |
