>> How often does it really make sense to keep such a product in this local variable? > > It depends. Lets take it the other way round. If I this in a review I'd > suggest the submitter to create a local variable for the multiplication > to get rid of the line break. It's avoidable. I imagine that there are further possibilities to improve the involved programming for various arrays. > And again, the compiler will optimize it away. > > Apart from the fact that you haven't tested your patch at all: This is true in principle as I could compile the source code adjustment at least. > jthumshirn@linux-x5ow:linux (test)$ git am ~/\[PATCH\ 3_5\]\ IB_hfi1\:\ > Adjust\ another\ size\ determination\ in\ > hfi1_user_sdma_alloc_queues\(\).eml > Applying: IB/hfi1: Adjust another size determination in > hfi1_user_sdma_alloc_queues() > jthumshirn@linux-x5ow:linux (test)$ make > drivers/infiniband/hw/hfi1/user_sdma.o CHK > include/config/kernel.release > CHK include/generated/uapi/linux/version.h > CHK include/generated/utsrelease.h > CHK include/generated/bounds.h > CHK include/generated/timeconst.h > CHK include/generated/asm-offsets.h > CALL scripts/checksyscalls.sh > CC drivers/infiniband/hw/hfi1/user_sdma.o > drivers/infiniband/hw/hfi1/user_sdma.c: In function > ‘hfi1_user_sdma_alloc_queues’: > drivers/infiniband/hw/hfi1/user_sdma.c:402:2: error: ‘memsize’ > undeclared (first use in this function) > memsize = sizeof(*pq->reqs) * hfi1_sdma_comp_ring_size; > ^ How do you think about to apply also the previous update step like “[PATCH 2/5] IB/hfi1: Use kcalloc() in hfi1_user_sdma_alloc_queues()”? > So to sum up: there is no evident improvement in the resulting binary There might not be a remarkable difference with the default software build parameters. > and you introduce a stylistic glitch (the new line break in a function call). There are different opinions about this implementation detail, aren't there? Regards, Markus -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
