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

[Leon Romanovsky <leon-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 1788 bytes --]

On Tue, May 03, 2016 at 12:54:05PM -0400, Dennis Dalessandro wrote:
> On Tue, May 03, 2016 at 07:24:57PM +0300, Leon Romanovsky wrote:
> >On Mon, May 02, 2016 at 03:55:02PM -0400, Dennis Dalessandro wrote:
> >>We also should be able to use any of these schemes to handle our eprom
> >>reading/writing. Adding eprom to IPoIB as Doug suggested is a fine plan, but
> >>we technically don't need to do it right now when we could make do with the
> >>"UI" functionality and hide the details in user space. In the future there
> >>may well be value in having an eprom capability in the rdma sub-system, but
> >>for now we believe we can avoid extending the kernel in this regard.
> >
> >Just to understand better your RFC. Are you asking from the community
> >excuse do not implement core functionality just because you don't need
> >it? Am I right?
> 
> The purpose of the RFC is to get the community's feedback on our plans to
> solve our UI/EPROM issue. The paragraphs [1] not snipped in your response
> focus on that. It comes down to:
> 
> Use resource0 which does not support locking vs use a file in
> /sys/kernel/debug.

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.

> 
> The point of the particular paragraph you are questioning is that I don't
> think we should add more code and complexity to the kernel for something
> that is not needed.
> 
> [1] http://marc.info/?l=linux-rdma&m=146221891012428&w=2
> 
> -Denny

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]