Re: [RFC] Proposal to address hfi1 UI and EPROM devices

Dennis Dalessandro
2016-05-04T12:36:21Z

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