Re: [PATCH 2/2] fpga: add FPGA manager debugfs

From: Federico Vaga
Date: Fri Aug 17 2018 - 10:54:27 EST

On Friday, August 17, 2018 3:19:24 PM CEST Alan Tull wrote:
> On Fri, Aug 17, 2018, 2:00 AM Federico Vaga <federico.vaga@xxxxxxx> wrote:
> > Hi Mortiz,
> >
> > I'm not 100% into the problem to understand all cases. I'm putting on the
> > table the point of view, mainly, of an user. If you say there are problems
> > here or there I believe you. At the beginning, you did not say that this
> > interface may introduce problems (and I'm interested in those problems
> > since I
> > implemented one and we are using it), but that you fear that it becomes
> > the
> > default (usually, being a default is a good thing).
> >
> > Since you and Alan are working on this for a long time, you can read each
> > other mind, but I need a more verbose email to understand ^_^'
> >
> > Of course the interface must be safe, I totally agree. In order to make me
> > understand what are the issues, can you list some of them?
> Before we repeat what the doc l posted says, could you look at it and
> comment on what I'm not saying there?

I read it, but do you mean that the problems you foresee are only the ones
listed in there? If this is so, comments:

loading devices
It is true that it is a problem, and probably it is clear to everyone who will
try to use such interface: "and now how do I load my devices?". But this is
only a possible case, the FPGA may run without device driver and in this case
it is perfectly fine for production.

If the answer to the above question is: "ok, let me see where my devices are
in the memory ..." well if the machine crashes, it's their problem. This
problem exists even without the FPGA manager.

My understand is that it is optional. Developers are allowed to not implement
the bridge's operations. Which probably means that it does not exist or it is
not needed.
When an user uses this interface from userspace it shouldn't be hard to detect
if the operation is risky or not (bridge enabled/disabled). And if it is
risky, the operation fails with EPERM, EBUSY.

I have to say that I'm not familiar with the bridge design, perhaps I'm
missing something.

Yes, those are problems but I think they do not justify the label "not for
production": in some cases I think is fine.