On Wed, May 04, 2016 at 07:41:07AM +0300, Leon Romanovsky wrote:
I didn't quote the whole email because I didn't see any question in
these 3 options:
* First option - doesn't meet the requirements and hard to extend.
* Second option - doesn't meet the requirements and HW limitations
* Third option - presented as one possible option and looks like the
correct one.
And the real question is "where" do you need to implement third option.
And to remove the tension, all what you was supposed to ask can be
summarized in one question: "Do we have other customers for EEPROM in
our RDMA stack?". If the answer is yes, you will need to implement it in
core, and if the answer is no, you will implement it in your driver.
Hope it helps.
I think it's slightly more complicated than that. There are three options
really: core, driver, or get it out of the kernel.
Whether we have other things that need EEPROM in the RDMA stack is only part
of the question. We also should consider: do we have customers for EEPROM in
the RDMA stack that could program/access said EEPROM using user space and
are instead doing it in a driver?
If that is the case then I'd say they should follow the path we are planning
for hfi1 and remove the code from the kernel. If there is already a way to
do something from user space that should be leveraged as much as possible.
-Denny
--
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
