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
| Michal Piotrowski | Re: 2.6.23-rc3-mm1 |
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Fred Tyler | Slow, persistent memory leak in 2.6.20 |
| Roland Dreier | Re: Integration of SCST in the mainstream Linux kernel |
git: | |
| David Miller | [GIT]: Networking |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| Antonio Almeida | HTB accuracy for high speed |
