[ovs-dev] Mail System Error - Returned Mail
___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH v7 09/16] SUNRPC/cache: use new hashtable implementation
On Mon, Oct 29, 2012 at 5:42 AM, Mathieu Desnoyers wrote: > > So defining e.g.: > > #include > > #define DFR_HASH_BITS (PAGE_SHIFT - ilog2(BITS_PER_LONG)) > > would keep the intended behavior in all cases: use one page for the hash > array. Well, since that wasn't true before either because of the long-time bug you point out, clearly the page size isn't all that important. I think it's more important to have small and simple code, and "9" is certainly that, compared to playing ilog2 games with not-so-obvious things. Because there's no reason to believe that '9' is in any way a worse random number than something page-shift-related, is there? And getting away from *previous* overly-complicated size calculations that had been broken because they were too complicated and random, sounds like a good idea. Linus ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH v8 01/16] hashtable: introduce a small and naive hashtable
On Tue, Oct 30, 2012 at 6:16 PM, Steven Rostedt wrote:
>
> ({\
> sizeof(val) <= 4 ? hash_32(val, bits) : hash_long(val, bits); \
> })
>
> Is the better way to go. We are C programmers, we like to see the ?: on
> a single line if possible. The way you have it, looks like three
> statements run consecutively.
If we're C programmers, why use the non-standard statement-expression
at all? And split it onto three lines when it's just a single one?
But whatever. This series has gotten way too much bike-shedding
anyway. I think it should just be applied, since it does remove lines
of code overall. I'd even possibly apply it to mainline, but it seems
to be against linux-next.
Linus
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH v8 01/16] hashtable: introduce a small and naive hashtable
On Tue, Oct 30, 2012 at 6:36 PM, Sasha Levin wrote: > > I can either rebase that on top of mainline, or we can ask maintainers > to take it to their own trees if you take only 01/16 into mainline. > What would you prefer? I don't really care deeply. The only reason to merge it now would be to avoid any pain with it during the next merge window. Just taking 01/16 might be the sanest way to do that, then the rest can trickle in independently at their own leisure. Linus ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH v8 01/16] hashtable: introduce a small and naive hashtable
On Tue, Oct 30, 2012 at 7:24 PM, Al Viro wrote: > > BTW, how serious have you been back at KS when you were talking about > pull requests killing a thousand of lines of code being acceptable > at any point in the cycle? Well... I'm absolutely a lot more open to pull requests that kill code than not, but I have to admit to being a bit more worried about stuff like your execve/fork patches that touch very low-level code. So I think I'll punt that for 3.8 anyway. Linus ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
Re: [ovs-dev] [PATCH v8 01/16] hashtable: introduce a small and naive hashtable
On Tue, Oct 30, 2012 at 8:24 PM, Al Viro wrote: > > Oh, well... there go my blackmail plans ;-) Seriously, though, I'm at loss > regarding several embedded architectures - arch/score, in particular, > seems to be completely orphaned. Don't worry about it. Do a best-effort, and if nobody ever reacts about some odd-ball architecture, whatever. We won't start deleting architectures over something like this, but it might be another sign down the road that some arch code can be removed entirely. So it's not arch/score I'd worry about. It's all the *other* architectures.. Linus ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
